Introduce getOptions about loader-utils

[elfey]

My question is, why force every single user of Webpack to update his config when you can just change the underlying code that processes the config to do this automatically?

Right now we're stuck with this deprecation warning and no idea how to fix it.

Edit: this isn't an issue application developers have to worry about, this is for webpack-loader developers.

[blackdynamo]

Hello, just wondering what I might be doing wrong that's causing this warning. I am trying to follow this issue and understand where things are going and have narrowed down to the following causing the warning vs not.

Case 1: Having an options property causes the warning

  module: {
    rules: [
      {
        test: /\.jsx?$/,
        loader: "babel-loader",
        exclude: /node_modules/,
        options: {
          // https://github.com/babel/babel-loader#options
          cacheDirectory: isDebug,
        }
      },
    ]
  },

[16:48:12] Starting "build"...
[16:48:12] Starting "clean"...
[16:48:13] Finished "clean" after 120 ms
[16:48:13] Starting "bundle"...
(node:85959) 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.
Child
    Time: 319ms
         Asset     Size  Chunks             Chunk Names
        api.js  26.5 kB       0  [emitted]  main
    api.js.map  41.2 kB       0  [emitted]  main
Child
    Time: 383ms
             Asset     Size  Chunks             Chunk Names
        service.js  47.8 kB       0  [emitted]  main
    service.js.map  57.5 kB       0  [emitted]  main
[16:48:13] Finished "bundle" after 452 ms
[16:48:13] Finished "build" after 574 ms

Case 2: Removing the options property removes the warning

  module: {
    rules: [
      {
        test: /\.jsx?$/,
        loader: "babel-loader",
        exclude: /node_modules/,
        options: {
          // https://github.com/babel/babel-loader#options
          cacheDirectory: isDebug,
        }
      },
    ]
  },

[16:48:43] Starting "build"...
[16:48:43] Starting "clean"...
[16:48:43] Finished "clean" after 124 ms
[16:48:43] Starting "bundle"...
Child
    Time: 977ms
         Asset     Size  Chunks             Chunk Names
        api.js  26.5 kB       0  [emitted]  main
    api.js.map  41.2 kB       0  [emitted]  main
Child
    Time: 1143ms
             Asset     Size  Chunks             Chunk Names
        service.js  47.8 kB       0  [emitted]  main
    service.js.map  57.5 kB       0  [emitted]  main
[16:48:44] Finished "bundle" after 1215 ms
[16:48:44] Finished "build" after 1342 ms

[rainjay]

set process.noDeprecation = true , the warning will be removed

[hulkish]

I think it'd be helpful if this logged warning specified the name of the loader in violation of this spec.

[jhnns]

Sorry for the confusion. This deprecation warning is not for webpack users, but for loader authors. I've added a paragraph in my first comment to clarify that. Use process.traceDeprecation = true in your webpack.config.js to find out which loader is causing this deprecation warning.

We had to go this way because depending on how the loader is using the result of parseQuery it can have bad side-effects, like bloating the bundle (see webpack-contrib/sass-loader#368 (comment)).

@artisin Thanks for pointing that out. I didn't know that there are situations where an empty string is passed to parseQuery. Unfortunately, there were little tests so it was hard to find all use-cases. I'll release a fix in the next hours. @johnnyreilly I think, that fix should also solve your problem?

[MatteoGabriele]

@jgentes just add literally process.traceDeprecation = true in your webpack.config.js file, not the actual webpack object

[MatteoGabriele]

@pedrommuller you don't, it's a node property. just add that at the top of your entry point.

process.traceDeprecation = true

module.exports = {
  // my webpack configuration object
}

[jhnns]

This is not a good workaround. The babel-loader will soon publish a new version that removes the deprecation warning.

[hulkish]

@jhnns how about just spit out the query or options used? That would make it pretty clear as to what is using it.

[jayullman]

I am also receiving this warning. I am admittedly new to Webpack and am not sure if this is something that I need to change in my code, or if this is something that will get corrected down the road.

Here is the code that is causing the warning:

module: {
    rules: [
      {
        test: /\.js$/, // include .js files
        exclude: /node_modules/, // exclude any and all files in the node_modules folder
        use:
          {
            loader: "jshint-loader", 
            options: { esversion: 6, camelcase: true, emitErrors: false, failOnHint: false }
          }
      },

Any advice would be greatly appreciated. Thanks!

[hulkish]

surely th ere must be a way to log the name of the offending loader here?

[artisin]

I attempted to update to version 1.0, however, loaderUtils.getOptions(this) throws an error at parseQuery(query) if said query is an empty String at initial validation: query.substr(0, 1) !== "?". I'm assuming this is not by design since it implies a user must specify an option property in the config regardless of whether a user has options to apply, although, maybe I'm interpreting this incorrectly.

[MatteoGabriele]

@jgentes yeah for me neither! I don't really get this, usually patches are meant to be patches: they fix something, don't bring strange warnings in the console.
I have no idea on how to solve this one

[johnnyreilly]

Ah... I think this may be down to babel-loader using 0.2.16....

[pla2aroi]

(node:47141) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see #56
parseQuery() will be replaced with getOptions() in the next major version of loader-utils.

Solve my problem

Before

   {
        test: /\.js?$/,
        exclude: /node_modules|\.git/,
        loader: 'babel-loader',
        options: {
          babelrc: false,
          presets: ['es2015', 'stage-0', 'react'],
          cacheDirectory: true
        }
      }

After editing, it works.

      {
        test: /\.js?$/,
        exclude: /node_modules|\.git/,
        loader: 'babel-loader?-babelrc,+cacheDirectory,presets[]=es2015,presets[]=stage-0,presets[]=react',
        // options: {
        //   babelrc: false,
        //   presets: ['es2015', 'stage-0', 'react'],
        //   cacheDirectory: true
        // }
      }

[elfey]

@jagasan that's completely irrelevant to this issue. And if you want my opinion on it, it's likely because axios isn't defined on this.

You're better off asking questions like that on Stack Overflow or on another website.

[jhnns]

Have you read the first post in this thread? What is confusing about it?

[hulkish]

@jhnns i think he just means that we wanna see this warning go away and would like a way to handle it correctly

[johnnyreilly]

Just tried to upgrade ts-loader to use the new version of loader-utils here: TypeStrong/ts-loader#475

I haven't had chance to look into it but there's issues: https://travis-ci.org/TypeStrong/ts-loader/jobs/203704607

[johnnyreilly]

BTW in our test packs we have migrated to use options in place of query on the understanding that query was deprecated and options was the new hotness.

[johnnyreilly]

Just having a look at the error output; seeing this:

Error: A valid query string passed to parseQuery should begin with '?'

Will your fix resolve that as well?

[johnnyreilly]

Actually I've just had a look at the code in the change and spotted a potential problem: https://github.com/webpack/loader-utils/pull/65/files#diff-55c2772ed44f17a0079fc5dabe37be63R6

Shouldn't the getOptions function take into account the options value? It actually does this:

function getOptions(loaderContext) {
	const query = loaderContext.query;
	if(typeof query === "string") {
		return parseQuery(loaderContext.query);
	}
	return query;
}

Should it not use options if it is passed? Something like this:

function getOptions(loaderContext) {
	const query = loaderContext.query;
	if(typeof query === "string") {
		return parseQuery(loaderContext.query);
	}
	return query || loaderContext.options; // If query is undefined then use options
}

[jhnns]

Will your fix resolve that as well?

Yes

Shouldn't the getOptions function take into account the options value?

No. loaderContext.options are the webpack options from the webpack.config.js (bad naming 😞). They will probably be removed someday because they make it hard to execute loaders in separate processes.

[johnnyreilly]

Will your fix resolve that as well?

Yes

Awesome.

No. loaderContext.options are the webpack options from the webpack.config.js (bad naming 😞).

huh - does that mean when you pass options in your webpack.config.js that gets turned into query on the other side? Sounds... confusing!

[blackdynamo]

@jhnns Thanks for the clarification on the warning. I will disregard the warning until it disappears :)

[jhnns]

Just shipped 1.0.1. Try it out! :)

[johnnyreilly]

Thanks - just queued a build: https://travis-ci.org/TypeStrong/ts-loader/builds/203855056

[jhnns]

The build is failing. getOptions() may return null if no options were specified, see README. I've added that later because the handling was not very consistent before that.

[johnnyreilly]

Thanks @jhnns - when I get a chance I'll check that the code handles getOptions returning null; I have a feeling it doesn't at present

[johnnyreilly]

Looking good - just merged my PR.

[johnnyreilly]

Not sure if this is related but I've started encountering situations where both of the following are either null / undefined or their mtimes property is:

        var watcher = watching.compiler.watchFileSystem.watcher ||
            watching.compiler.watchFileSystem.wfs.watcher;

        Object.keys(watcher.mtimes) // Problems!

I've just started looking at a PR for ts-loader to workaround this:

TypeStrong/ts-loader#481

But I'm kind of surprised it's happened. I only experienced it when I did a fresh npm install. Is this related to loader-utils do you think? I only ask as it started happening within the last day.

[jgentes]

Maybe a dumb question, but when I add process: { traceDeprecation: true } to my webpack.config file, I get an error: WebpackOptionsValidationError: Invalid configuration object.

[jgentes]

Got it, thanks @MatteoGabriele - unfortunately it didn't produce any new information about the source :/

[johnnyreilly]

Hey @jhnns,

We released 2.0,1 of ts-loader last night: https://github.com/TypeStrong/ts-loader/releases/tag/v2.0.1

This included ts-loader moving to v1.x of loader-utils. However, we're still experiencing this message:

(node:44024) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see #56

Do you know why? I would expect it to vanish now we're using 1.x...

[jquense]

yeah, I have no idea what is throwing this to know if I need to fix something in a loader i've written. right now it's not something I can fix even if I wanted too

[donaldpipowitch]

Keep this:

• Addressable warnings/errors. It's great log an URL to this issue. 👍

While I like good deprecation warnings, I'd change this:

• Please don't use process.traceDeprecation = true in the future.This logs to stderr and I know this could be confused with actual errors and not warnings. I'd prefer a webpack specific log setting for warnings, so users could opt-in or opt-out for deprecation warnings on a per lib basis and don't rely on a global setting.
• Either warn about deprecations or don't warn. But don't introduce a verbose and non-verbose warning with additional configuration. IMHO it would have been nicer, if the warning would say which loader causes this be default. (It looks likeprocess.traceDeprecation = true doesn't even work for me :( It tells me nothing new.) If you really want to have a more verbose warning you already have this issue.

[jhnns]

@donaldpipowitch thanks for the feedback, but we are using a nodejs core module for deprecation. This way of showing deprecation warnings, also with stack traces by setting process.traceDeprecation = true, is not unique to this module. It's how most node modules deprecate things.

We have chosen to use this noisy way of deprecating things because it can have really bad side-effects if it is not fixed.

[donaldpipowitch]

@jhnns Yeah, I know this is from a core module, but still... To be honest I haven't seen this that often in several years with Node development, so I'm not sure that this is what most Node developers do. I personally think in log levels first (like a warning) instead of topics (like a deprecation) and because I think deprecations are like any other warning coming from a lib there is always a different expectation for me, because any other warning from Webpack is formatted in a different way. So from a DX point of view I have to look twice, that this is actually a warning and not an unhandled error (that's always what I think first) and that this warning comes from Webpack. But maybe it's just me...

Nothing against being noisy. As I said you could even be more noisier for me by logging the loaders which cause this warning, too.

[pedrommuller]

hey guys, jus a quick question how do you set up process.traceDeprecation = true in your webpack.config?

[pedrommuller]

@MatteoGabriele makes totally sense, thanks!

[jhnns]

@donaldpipowitch

So from a DX point of view I have to look twice, that this is actually a warning and not an unhandled error (that's always what I think first) and that this warning comes from Webpack. But maybe it's just me...

No, I agree with you that this is not very user friendly. I thought that this is the way how you deprecate things in node since it is listed in the documentation and there are special cli flags for it. However, after reading nodejs/node#1883 I'm not so sure anymore if util.deprecate() is meant for userland modules. Especially the (node) prefix is very confusing.

We could have tried to parse the loader name from the stack, but I think most loaders have already addressed it.

[zhe-he]

I met the same problem as blackdynamo ，
{ test: /\.js$/, exclude:/(node_modules|lib)/, use: [ { loader:'babel-loader', options: {presets: [["es2015", { "modules": false }]]} } ] }
It is passed when not use options.
As an obsessive-compulsive disorder sufferer, I hope the author can solve as soon as possible. thanks!

[abz123]

Same/similar problems as others:

(node:5349) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see #56
parseQuery() will be replaced with getOptions() in the next major version of loader-utils.
Hash: ab5512b5fb5f788546ea
Version: webpack 2.2.1

[rthummalapally]

So I'm still running into the same issue. I've placed process.noDeprecation = true; into my config to no avail. Is there a fix for this other than that? I'm new to all this webpack stuff so pardon my ignorance.

bundle exec rake assets:compile_assets

[32m07 03 2017 23:18:30.598:INFO [karma]: [39mKarma v0.13.22 server started at http://localhost:9876/
[32m07 03 2017 23:18:30.606:INFO [launcher]: [39mStarting browser Firefox
[32m07 03 2017 23:18:30.612:INFO [launcher]: [39mStarting browser Chrome
[32m07 03 2017 23:18:31.432:INFO [Chrome 56.0.2924 (Mac OS X 10.11.5)]: [39mConnected on socket /#uF7y1NDn_2ggOAWGAAAA with id 58584140
Chrome 56.0.2924 (Mac OS X 10.11.5): Executed 0 of 0 ERROR (0.002 secs / 0 secs)
[32m07 03 2017 23:18:32.444:INFO [Firefox 45.0.0 (Mac OS X 10.11.0)]: [39mConnected on socket /#zDMNrGuEKclQyJY2AAAB with id 64613294
Firefox 45.0.0 (Mac OS X 10.11.0): Executed 0 of 0 ERROR (0.001 secs / 0 secs)

loaderUtils.parseQuery() received a non-string value which can be problematic, see #56
parseQuery() will be replaced with getOptions() in the next major version of loader-utils.

[MCodyB]

@jhnns Just FYI, for the Rails noobs webpack.config.js will be found in config/webpack/shared.js, if they've set included it using the webpack gem that will be included in Rails 5.1.

[jagasan]

hi i am getting error get method undefined
mounted: function() {
var self = this;
self.axios.get('https://jsonplaceholder.typicode.com/users')
.then(function(response){
console.log('response'+response);
}.bind(this));

    },

[Oblik-Design]

is there a suggested fix ? the thread is really confusing.. I get anxious working with warnings !

[Oblik-Design]

you are joking right ? i'm not a dedicated fan to this project, all I aiming for is to not have warnings meant for others... so now, please, I'm pretty sure i'm not the only one in this situation.

[jhnns]

The deprecation warning is for webpack loader authors, because calling parseQuery with a non-string value can have bad side-effects (see below).

Are you a webpack loader author? If yes, replace parseQuery with getOptions as described in the README

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.

Are you a webpack user? Probably yes. Then you need to find out which of your loaders is causing this warning. Copy & paste this line:

process.traceDeprecation = true;

into the first line of your webpack.config.js and take a look at the output in the console. You should see in the stack trace which loader is causing the warning. After you've identified the loader, go to the repository and:

Please file an issue in the loader's repository.

[elfey]

@Oblik-Design this is open source software... and as you would expect; software evolves and deprecates things. This deprecation needed to be public so that loader authors would hear about it.

And despite this common knowledge, you continue to wine about a harmless deprecation warning and downvote tolerant posts.

• Wake up.
• You're not dead.
• Your project isn't dead.
• Everything still works as before.
• If your OCD is kicking in, put a bullet in its head - nobody cares.

These contributors are doing us a favor (so stop wining).

If you felt I was harsh in this criticism of your attitude: good. That's how it was intended.

@jhnns thank you for your work and your tolerance. Maybe it's best this thread is locked.

[Oblik-Design]

wow, you have read this wrong, english is a third language, must be my fault. no my package does not work properly and adding that process.traceDeprecation = true; did not change a thing.

[jhnns]

@Oblik-Design if you still don't know what to do, you can safely ignore this deprecation warning. It will disappear over time if you keep your packages up-to-date.

[jhnns]

This deprecation warning is for webpack loader authors. If you've written your own loader, then please follow the instructions from the first post and the current README.

If you're a webpack user who is using another loader, 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.

If you have no clue what this is all about, you can safely ignore the deprecation warning. It will disappear over time if you keep your packages up-to-date.