Closed 0gust1 closed 5 years ago
Corresponding PR : https://github.com/sveltejs/svelte-loader/pull/90
Summed up explanation :
this.options
(which now returns undefined
), so the final option object is filled with loader-utils.getOptions(this)
content only.I can push the code of the minimal test-case project I used, if needed.
Is this.options
needed? getOptions()
uses this.query
and it seems to be supported since webpack v1.
@esarbanis do you remember why you added this.options
here?
@mrkishi thanks for the precision ! I confess I lacked some energy to dig on the evolution of the API on webpack side. I will do some tests on my minimal test-case. I just hope we won't hit some edge case, trying to get rid of this.options
, webpackism is hairy sometimes ^^
Some links to webpack loader apis :
this.options
is deprecated since webpack 3 and removed in webpack 4 : https://webpack.js.org/api/loaders/#thisoptions getOptions
from loader-utils
is the recommended way to go https://github.com/webpack/loader-utils#getoptionsI still don't know why this.options
was used, but it worth noting that getOptions
has his own sets of bugs in the past (apparently linked to "query paremeters" expressed options).
getOptions
appeared in version 1.0.0
(21 Feb 2017) of loader-utils
.
I'll make some tests and push changes on my PR today (which should be muuuuch cleaner :) ). Thanks !
@mrkishi , @esarbanis : I did some analysis again.
tldr: removing this.options
does the job, but breaks a test that maybe should rewritten.
should preprocess successfully
and should not preprocess successfully
{width:50px;height:50px}
in the preprocessed result and final compiled result).New test in PR soon.
@mrkishi @esarbanis @Rich-Harris @ekhaled @Conduitry
CI is green, everything seems OK. Can you check #90 ?
Released 2.13.4 with the fix — thanks
Sorry for the annoying issue :-/
TLDR :
It's a cross bug between :
this.options
andloader-utils.getOptions(this)
to handle options.this.options
was deprecated in webpack3 and removed in webpack4.loader-utils.getOptions(this)
is the right way to do. It appeared in version 1.0.0 (21 Feb 2017) of loader-utils and seems supported since webpack v1edit: proposed pull request : #90 edit: related issue : #88 edit: possibly related issue/pr : #87
Below, all the analysis I did investigating the issue. Sorry, it's a bit verbose.
Context : Our big project is stuck to webpack 3 at the moment (due to a bug in webpack 4 that will be resolved in webpack 5).
This loader seems to break in webpack3. We have been able to reconstruct a minimal case (using the svelte-app template and making a dichotomy with webpack3 vs webpack4)
let { js, css, warnings } = normalize(compile(processed.toString(), compileOptions));
The kind of errors we have :
On our other project, it's not
entry
butcontext
.After further analysis, it seems that the svelte V3 compiler doesn't like the configuration feeded to it when it comes from webpack 3. The
validate_options()
function of the compiler reject it.Config is inited here : https://github.com/sveltejs/svelte-loader/blob/b11b4e91fc4ba3f081f243e503c0fb0e424c4784/index.js#L109 where
this.options
is :undefined
(because it was finally deprecated)Config is transformed along the way (into a compileOptions object) and, after that, it's used here : https://github.com/sveltejs/svelte-loader/blob/b11b4e91fc4ba3f081f243e503c0fb0e424c4784/index.js#L146
In the minimal test case we have :
compileOptions with webpack 3 and svelte 3
compileOptions with webpack 4 and svelte 3