【填坑】vue+webpack 升级后在原有项目上的适配问题

古人云：不作死就不会死

本人的项目是 vue + webpack，vue单文件中使用了 Jade 模板与 less 预编译器

起因是因为谈论到 Jade 模板问题，Jade 早已改名为 Pug，并且发布了2.0版本，想着不如升级了吧，顺便把 webpack 与 vue 也一并升级了，事实证明，升级需谨慎 = =

首先之前的版本如下：

"vue": "2.4.2"
"webpack": "2.7.0"复制代码

升级后的版本为：

"vue": "2.5.7"
"webpack": "3.8.1"复制代码

运行 npm update ，一切正常，然而运行 vue 项目就开始报错了

// webpack 报错
(node:45948) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see https://github.com/webpack/loader-utils/issues/56
parseQuery() will be replaced with getOptions() in the next major version of loader-utils.

// vue报错
// 略过一些重复的报错
warning  in ./src/pages/List.vue

(Emitted value instead of an instance of Error) the "scope" attribute for scoped slots have been deprecated and replaced by "slot-scope" since 2.5. The new "slot-scope" attribute can also be used on plain elements in addition to

【填坑】vue+webpack 升级后在原有项目上的适配问题

1. loaderUtils.parseQuery()

解决方案：

如果你还想看一下具体的原因，可以继续看下去

Starting with webpack 2, it is also possible to pass an object reference from the `webpack.config.js` to the loader. This is a lot more straight-forward and it allows the use of non-stringifyable values like functions.

For compatibility reasons, this object is still read from the loader context via `this.query`. Thus, `this.query` can either be the options object from the `webpack.config.js` or an actual loader query string. The current implementation of parseQuery just returns `this.query` if it's not a string.

Unfortunately, this leads to a situation where the loader re-uses the options object across multiple loader invocations. This can be a problem if the loader modifies the object (for instance, to add sane defaults). See jtangelder/sass-loader#368 (comment).

Modifying the object was totally fine with webpack 1 since `this.query` was always a string. Thus, `parseQuery` would always return a fresh object.

Starting with the next major version of loader-utils, we will unify the way of reading the loader options:

We will remove `parseQuery` and `getLoaderConfig`

We will add `getOptions` as the only way to get the loader options. It will look like this:

The returned options object is read-only, you should not modify it. This is because `getOptions` can not make assumptions on how to clone the object correctly.

原文还好心的提醒了我们一下如何调试 webpack 以查明是哪个 `loader` 导致的报错，可以在 `webpack.config.js` 中设置 `process.traceDeprecation = true`

2. vue - scope

解决方案

那么为何要用作用域插槽呢，感兴趣的朋友可以继续读下去

在 vue 的 version >= 2.5 后，使用的方式略微有些变化，但是更加直观，去掉了中间的 `template` 组件，并且把属性名 `scope` 改为了 `slot-scope`

以上代码的 demo 可以参见这里

3. 番外篇：vue-loader 的报错

在 `webpack.config.js` 配置中添加一个别名，见 vue官方文档：运行时-编译器-vs-只包含运行时

最终在 vue-loader 的更新文档中找到了原因

具体说明

New

Breaking Changes

结语

你可能感兴趣的:(【填坑】vue+webpack 升级后在原有项目上的适配问题)

【填坑】vue+webpack 升级后在原有项目上的适配问题

1. loaderUtils.parseQuery()

解决方案：

如果你还想看一下具体的原因，可以继续看下去

Starting with webpack 2, it is also possible to pass an object reference from the webpack.config.js to the loader. This is a lot more straight-forward and it allows the use of non-stringifyable values like functions.

For compatibility reasons, this object is still read from the loader context via this.query. Thus, this.query can either be the options object from the webpack.config.js or an actual loader query string. The current implementation of parseQuery just returns this.query if it's not a string.

Unfortunately, this leads to a situation where the loader re-uses the options object across multiple loader invocations. This can be a problem if the loader modifies the object (for instance, to add sane defaults). See jtangelder/sass-loader#368 (comment).

Modifying the object was totally fine with webpack 1 since this.query was always a string. Thus, parseQuery would always return a fresh object.

Starting with the next major version of loader-utils, we will unify the way of reading the loader options:

We will remove parseQuery and getLoaderConfig

We will add getOptions as the only way to get the loader options. It will look like this:

The returned options object is read-only, you should not modify it. This is because getOptions can not make assumptions on how to clone the object correctly.

原文还好心的提醒了我们一下如何调试 webpack 以查明是哪个 loader 导致的报错，可以在 webpack.config.js 中设置 process.traceDeprecation = true

2. vue - scope

解决方案

那么为何要用作用域插槽呢，感兴趣的朋友可以继续读下去

在 vue 的 version >= 2.5 后，使用的方式略微有些变化，但是更加直观，去掉了中间的 template 组件，并且把属性名 scope 改为了 slot-scope

以上代码的 demo 可以参见 这里

3. 番外篇：vue-loader 的报错

在 webpack.config.js 配置中添加一个别名，见 vue官方文档：运行时-编译器-vs-只包含运行时

最终在 vue-loader 的更新文档中找到了原因

具体说明

New

Breaking Changes

结语

你可能感兴趣的:(【填坑】vue+webpack 升级后在原有项目上的适配问题)

Starting with webpack 2, it is also possible to pass an object reference from the `webpack.config.js` to the loader. This is a lot more straight-forward and it allows the use of non-stringifyable values like functions.

For compatibility reasons, this object is still read from the loader context via `this.query`. Thus, `this.query` can either be the options object from the `webpack.config.js` or an actual loader query string. The current implementation of parseQuery just returns `this.query` if it's not a string.

Modifying the object was totally fine with webpack 1 since `this.query` was always a string. Thus, `parseQuery` would always return a fresh object.

We will remove `parseQuery` and `getLoaderConfig`

We will add `getOptions` as the only way to get the loader options. It will look like this:

The returned options object is read-only, you should not modify it. This is because `getOptions` can not make assumptions on how to clone the object correctly.

原文还好心的提醒了我们一下如何调试 webpack 以查明是哪个 `loader` 导致的报错，可以在 `webpack.config.js` 中设置 `process.traceDeprecation = true`

在 vue 的 version >= 2.5 后，使用的方式略微有些变化，但是更加直观，去掉了中间的 `template` 组件，并且把属性名 `scope` 改为了 `slot-scope`

以上代码的 demo 可以参见这里

在 `webpack.config.js` 配置中添加一个别名，见 vue官方文档：运行时-编译器-vs-只包含运行时