-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce getOptions #56
Comments
This deprecation warning is intended to alarm loader authors that passing an object to parseQuery and then modifying it might lead to unintended behavior. #56
This deprecation warning is intended to alarm loader authors that passing an object to parseQuery and then modifying it might lead to unintended behavior. #56
This deprecation warning is intended to alarm loader authors that passing an object to parseQuery and then modifying it might lead to unintended behavior. #56
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
Case 2: Removing the options property removes the warning
|
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. |
I attempted to update to version |
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:
Any advice would be greatly appreciated. Thanks! |
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 |
BTW in our test packs we have migrated to use |
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 We had to go this way because depending on how the loader is using the result of @artisin Thanks for pointing that out. I didn't know that there are situations where an empty string is passed to |
Just having a look at the error output; seeing this:
Will your fix resolve that as well? |
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
Should it not use
|
Yes
No. |
Awesome.
huh - does that mean when you pass |
@jhnns Thanks for the clarification on the warning. I will disregard the warning until it disappears :) |
Unify the handling of unexpected queries: 1. If `this.query` is a string: - Tries to parse the query string and returns a new object - Throws if it's not a valid query string 2. If `this.query` is object-like, it just returns `this.query` 3. In any other case, it just returns `null` #56
Just shipped |
Thanks - just queued a build: https://travis-ci.org/TypeStrong/ts-loader/builds/203855056 |
The build is failing. |
When run build **loader-utils** issued this deprecation message: ``` loader option has been deprecated - replace with "use" (node:22316) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic ``` So based on **loader-utils** (See: webpack/loader-utils#56) and **babel-loader** (See: https://github.com/babel/babel-loader#options) documentation. **options** have been removed as object and used query string instead.
When run build **loader-utils** issued this deprecation message: ``` loader option has been deprecated - replace with "use" (node:22316) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic ``` So based on **loader-utils** (See: webpack/loader-utils#56) and **babel-loader** (See: https://github.com/babel/babel-loader#options) documentation. **options** have been removed as object and used query string instead.
When run build **loader-utils** issued this deprecation message: ``` loader option has been deprecated - replace with "use" (node:22316) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic ``` So based on **loader-utils** (See: webpack/loader-utils#56) and **babel-loader** (See: https://github.com/babel/babel-loader#options) documentation. **options** have been removed as object and used query string instead. Updated **fallbackLoader** to **fallback** Updated **loader** to **use**
(node:47141) DeprecationWarning: loaderUtils.parseQuery() received a non-string value which can be problematic, see #56 Solve my problem Before
After editing, it works.
|
This is not a good workaround. The babel-loader will soon publish a new version that removes the deprecation warning. |
hi i am getting error get method undefined
|
@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 You're better off asking questions like that on Stack Overflow or on another website. |
is there a suggested fix ? the thread is really confusing.. I get anxious working with warnings ! |
Have you read the first post in this thread? What is confusing about it? |
@jhnns i think he just means that we wanna see this warning go away and would like a way to handle it correctly |
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. |
Are you a webpack loader author? If yes, replace
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
|
@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.
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. |
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. |
@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. |
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 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. |
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 setprocess.traceDeprecation = true
in yourwebpack.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 thewebpack.config.js
or an actual loader query string. The current implementation ofparseQuery
just returnsthis.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-contrib/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:
parseQuery
andgetLoaderConfig
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.The text was updated successfully, but these errors were encountered: