Closed ghost closed 6 years ago
@erwin16 this line is referencing a source-map on the file system. Certainly some source-map is necessary for `resolve-url-loader to do its thing.
Usually the resolve-url-loader
is not the first loader in the chain. The source-map comes through the webpack internals and not specified in the file source-map comment.
From the error though, it seems like (under the hood) rework
can also load the source-map from the source file when it parses it. It seems that the file is simply not present in the dist
directory.
@bholloway I'm coming here because I was waiting for the fix of https://github.com/bholloway/resolve-url-loader/issues/79. Now, since you've rolled out the fix on npm, I have the same issue that @erwin16 encountered. This happened without a source code or webpack configuration change and did not occur in webpack < 4. Feel free to dig into it:
https://github.com/julmot/form-components/pull/9#pullrequestreview-101021117
I'm looking forward to a fix that I can update to webpack 4.
@bholloway I've noticed that I can't reproduce the error via Travis CI, only on my Windows 10 machine.
@julmot I cannot easily see from your Webpack config what the problem might be. Are you getting exactly the same error?
@bholloway Almost identical, yes. The yellow part is printed a few times, then the red part a few times afterwards.
Can you reproduce it locally?
$ git clone https://github.com/julmot/form-components.git && cd form-components && git checkout greenkeeper/webpack-4.0.0 && npm install && npm run build
@julmot I encounter
$ npm run build
Warning: fontforge not found. Please install fontforge and all other requirements: https://github.com/sapegin/grunt-webfont#installation Use --force to continue.
However this runs fine on MacOS
npm run webpack:dev
I am just spinning up a windows 10 environment now.
@bholloway You're right, I forgot to mention the pre-requirements: https://github.com/julmot/form-components/blob/master/CONTRIBUTING.md#requirements
@julmot
> npm run webpack:dev
I see an error in select-lite-arrow.scss
.
So then I go into node_modules/resolve-url-loader/index.js
and hack this...
function resolveUrlLoader(content, sourceMap) {
if (/select-lite-arrow\.scss/.test(this.resourcePath)) {
console.error(sourceMap.sources);
}
...
I get this at the top of the output...
[
'C:\\Users\\IEUser\\Documents\\form-components\\src\\components\\select\\select-lite-arrow\\C:\\Users\\IEUser\\Documents\\form-components\\src\\components\\select\\select-lite-arrow\\select-lite-arrow.scss',
'C:\\Users\\IEUser\\Documents\\form-components\\src\\components\\select\\select-lite-arrow\\C:\\Users\\IEUser\\Documents\\form-components\\src\\components\\_common\\_form-components-icons.scss',
'C:\\Users\\IEUser\\Documents\\form-components\\src\\components\\select\\select-lite-arrow\\C:\\Users\\IEUser\\Documents\\form-components\\src\\components\\_common\\_fonts.scss'
]
Which looks like the bug is in some loader preceding resolve-url-loader
.
But I suggest you use adjust-source-map-loader in your loader chain and set it to debug mode.
...
}, {
loader: 'resolve-url-loader'
}, {
loader: 'adjust-sourcemap-loader',
options: {
debug: /select-lite-arrow\.scss/
}
}, {
loader: 'postcss-loader',
...
This gives diagnoses the same bad sourcemap with less hackery.
So at this point we can say the fault is either postcss-loader
OR sass-loader
is at fault.
adjust-sourcemap-loader:
C:\Users\IEUser\Documents\bholloway\form-components\src\components\select\select-lite-arrow\select-lite-arrow.scss
@ C:\Users\IEUser\Documents\bholloway\form-components\node_modules\postcss-loader\lib\index.js??ref--5-5
INPUT C:\Users\IEUser\Documents\bholloway\form-components\src\components\select\select-lite-arrow\C:\Users\IEUser\Documents\bholloway\form-components\src\components\select\select-lite-arrow\select-lite-arrow.scss
C:\Users\IEUser\Documents\bholloway\form-components\src\components\select\select-lite-arrow\C:\Users\IEUser\Documents\bholloway\form-components\src\components\_common\_form-components-icons.scss
C:\Users\IEUser\Documents\bholloway\form-components\src\components\select\select-lite-arrow\C:\Users\IEUser\Documents\bholloway\form-components\src\components\_common\_fonts.scss
If you move adjust-sourcemap-loader
forward you will see that sass-loader
has a good output.
adjust-sourcemap-loader:
C:\Users\IEUser\Documents\bholloway\form-components\src\components\select\select-lite-arrow\select-lite-arrow.scss
@ C:\Users\IEUser\Documents\bholloway\form-components\node_modules\sass-loader\lib\loader.js??ref--5-6
INPUT src\components\select\select-lite-arrow\select-lite-arrow.scss
src\components\_common\_base.scss
src\components\_common\_variables.scss
src\components\_common\_form-components-icons.scss
src\components\_common\_fonts.scss
src\components\_common\_mixins.scss
src\components\_common\_variables.scss
ABSOLUTE C:\Users\IEUser\Documents\bholloway\form-components\src\components\select\select-lite-arrow\select-lite-arrow.scss
C:\Users\IEUser\Documents\bholloway\form-components\src\components\_common\_base.scss
C:\Users\IEUser\Documents\bholloway\form-components\src\components\_common\_variables.scss
C:\Users\IEUser\Documents\bholloway\form-components\src\components\_common\_form-components-icons.scss
C:\Users\IEUser\Documents\bholloway\form-components\src\components\_common\_fonts.scss
C:\Users\IEUser\Documents\bholloway\form-components\src\components\_common\_mixins.scss
C:\Users\IEUser\Documents\bholloway\form-components\src\components\_common\_variables.scss
Therefore I would say postcss-loader
is at fault.
EDIT - Definitely a Windows problem. Here is the output of postcss-loader
in MacOS. It is absolute but correct.
adjust-sourcemap-loader:
/Users/bholloway/Documents/bholloway/form-components/src/components/select/select-lite-arrow/select-lite-arrow.scss
@ /Users/bholloway/Documents/bholloway/form-components/node_modules/postcss-loader/lib/index.js??ref--5-5
INPUT /Users/bholloway/Documents/bholloway/form-components/src/components/select/select-lite-arrow/select-lite-arrow.scss
/Users/bholloway/Documents/bholloway/form-components/src/components/_common/_form-components-icons.scss
/Users/bholloway/Documents/bholloway/form-components/src/components/_common/_fonts.scss
ABSOLUTE /Users/bholloway/Documents/bholloway/form-components/src/components/select/select-lite-arrow/select-lite-arrow.scss
/Users/bholloway/Documents/bholloway/form-components/src/components/_common/_form-components-icons.scss
/Users/bholloway/Documents/bholloway/form-components/src/components/_common/_fonts.scss
@julmot please confirm my analysis if possible. From looking at the attached issue in postcss-loader they seem pretty adamant that its a resolve-url-loader
problem. What am I missing?
@bholloway I've tried the fix of https://github.com/postcss/postcss-loader/issues/340#issuecomment-368469624 and I can confirm it's working.
Looks like mozilla/source-map
(used by postcss
) has considered paths to be URIs for at least 2 years. Hence this silly concatenation on windows.
I note that postcss
state that "you should always set 'to' to generate correct source maps". I would bet this avoids the issue most of the time.
I'm going to mark this as invalid
based on @julmot 's issue.
@erwin16 sorry for the initial delay, I can reopen this if you need further help. I think your stackoverflow issue confirms my initial guess. I would suggest having 2 different rules for css so that raw css files do not encounter resolve-url-loader
, only your transpiled ones.
Please feel free to comment further here.
I raised this issue on stack overflow (
https://stackoverflow.com/questions/48608703/vue-js-webpack-error-importing-css-file-from-external-library/48617366#48617366
)Building a vue.js app w webpack, and using resolve-url-loader for external css library loading ( aos css animation library ) , I got an error when building my app...
I discover that the the aos.css file has a comented last lien at the end
Withi this line in the aos.css code , I get an error compilation phase
If I suppress this line, then compilation is OK
I asked michalsnik why this commented line is still in the aos.css file , but I don't understand why the resolve-url-loader take it in account , it's a commented line after all..
thanks for clarifying this issue ...