-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
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
feat: getOptions util for loader #10017
Conversation
For maintainers only:
|
lib/NormalModule.js
Outdated
|
||
if (query.substr(0, 1) === "{" && query.substr(-1) === "}") { | ||
try { | ||
options = parseJson(query); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we use json5
here? Because previously implementation used json5
https://github.com/webpack/loader-utils/blob/master/lib/parseQuery.js#L3
lib/NormalModule.js
Outdated
query = query.substr(1); | ||
|
||
// Allow to use `?foo=bar` in `options` | ||
if (query.substr(0, 1) === "?") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we support options: "?foo=bar"
? I can update schema to disable because query contains ??foo=bar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double ??
has a special meaning anyway so loader??foo=bar
is not legal.
I think we should deprecate support for options: "string"
at all (in config).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No we don't need to support options: "?foo=bar"
.
lib/NormalModule.js
Outdated
throw new WebpackError(`Cannot parse query string: ${e.message}`); | ||
} | ||
} else { | ||
options = querystring.parse(query); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we support specialValues https://github.com/webpack/loader-utils/blob/master/lib/parseQuery.js#L5?
Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon. |
lib/NormalModule.js
Outdated
} | ||
|
||
validateOptions(schema, options, { | ||
name: loaderName || "Unknown Loader", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think its fine to use getCurrentLoaderName()
here and omit the loaderName
argument.
lib/NormalModule.js
Outdated
query = query.substr(1); | ||
|
||
// Allow to use `?foo=bar` in `options` | ||
if (query.substr(0, 1) === "?") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
double ??
has a special meaning anyway so loader??foo=bar
is not legal.
I think we should deprecate support for options: "string"
at all (in config).
lib/NormalModule.js
Outdated
query = query.substr(1); | ||
|
||
// Allow to use `?foo=bar` in `options` | ||
if (query.substr(0, 1) === "?") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No we don't need to support options: "?foo=bar"
.
lib/NormalModule.js
Outdated
@@ -327,6 +330,50 @@ class NormalModule extends Module { | |||
}; | |||
const loaderContext = { | |||
version: 2, | |||
getOptions: (loaderName, schema) => { | |||
const loader = loaderContext.loaders[loaderContext.loaderIndex]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const loader = loaderContext.loaders[loaderContext.loaderIndex]; | |
const loader = this.getCurrentLoader(loaderContext); |
561fc0a
to
f9846f1
Compare
lib/NormalModule.js
Outdated
}); | ||
if (schema) { | ||
validateOptions(schema, options, { | ||
name: getCurrentLoaderName(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if i need to setup name for a loader? schema-utils
prefer the name
argument under name in schema
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, fix that. Now it uses schema.title
, but falls back to Loader
and options
(instead of the default Object
and configuration
).
Maybe fallbackName
and fallbackBaseDataPath
in the schema-utils API would be nice.
lib/NormalModule.js
Outdated
}); | ||
if (schema) { | ||
validateOptions(schema, options, { | ||
name: getCurrentLoaderName(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, fix that. Now it uses schema.title
, but falls back to Loader
and options
(instead of the default Object
and configuration
).
Maybe fallbackName
and fallbackBaseDataPath
in the schema-utils API would be nice.
name: getCurrentLoaderName(), | ||
baseDataPath: "options" | ||
name, | ||
baseDataPath |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about change behavior (prefer schema title
over arguments) in next schema-utils release?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think both behaviors make sense for different use cases.
The minimum test ratio has been reached. Thanks! |
Thanks |
I've created an issue to document this in webpack/webpack.js.org. |
|
New
getOptions
util for loader (part of migration loader-utils into core)What kind of change does this PR introduce?
feature
Did you add tests for your changes?
Yes, after feedback i will add more tests
Does this PR introduce a breaking change?
No
What needs to be documented once your changes are merged?
getOptions
now in core as part of loader context and have this function signature ->this.getOptions(schema?: JSONSchema)
.It differs from the
getOptions
from schema-utils. Upgrading a loader to the newgetOptions
is a breaking change for these reasons:?{arg:true}
->?{"arg":true}
true
false
andnull
won't be parsed as string but as primitive value). This is no longer the case forthis.getOptions
which uses native querystring parsing (from node.js).title
field in the schema can be used to customize the validation error message: e. g."title": "My Loader ooooptions"
will display errors likeInvalid ooooptions object. My Loader has been initialised using an ooooptions object that does not match the API schema. - ooooptions.foo.bar.baz should be a string.