The deprecation warning is for webpack loader authors, because calling parseQuery with a non-string value can have bad side-effects (see below). If you're a webpack user, you can set process.traceDeprecation = true in your webpack.config.js to find out which loader is causing this deprecation warning. Please file an issue in the loader's repository.

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 webpack/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:

const options = loaderUtils.getOptions(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.