Nested dependancies not loaded #1951
Comments
iamdriz
changed the title
|
I just ran into this today. Is there any solution apart from monkeypatching the packages? |
|
Just import the bits that your SCSS file use, eg: The above will only work if the imported SCSS does not have sub- |
|
@jakeNiemiec How is this related to tree-shaking? I think that @iamdriz correctly identified the issue of webpacker not being configured correctly to allow loading nested modules. At any rate - your solution does not work as well: @import "~@material/feature-targeting/_functions.scss";
@import "~@material/typography/mdc-typography";yields And yes, the file is there: |
|
@Quintasan The structure of
I was referring to how JS will "walk" the dependency tree, resolving all the needed dependencies. As far as I can tell, |
|
Oh, I see. That makes some sense but the question still stands - how do we
use the includePaths with webpacker. I tried several approaches, the latest
one using webpack-merge but none of them worked.
czw., 4 kwi 2019, 20:06 użytkownik Jake Niemiec <[email protected]>
napisał:
… @Quintasan <https:/Quintasan> The structure of
@material/feature-targeting is very different from bootstrap. *It seems
like the consensus is to useincludePaths as @iamdriz
<https:/iamdriz> said.* There seems to be a bunch of users
having this problem even within the
material-components/material-components-web repo. ref
<material-components/material-components-web#3985>
ref
<material-components/material-components-web#351>
How is this related to tree-shaking?
I was referring to how JS will "walk" the dependency tree, resolving all
the needed dependencies. As far as I can tell, includePaths breaks
certain stacks, so the feature remains opt-in? *Sorry for the incorrect
info*, I was conflating scss-loader with something like imports-loader 😅.
(includePaths != "paths to include"` )
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1951 (comment)>,
or mute the thread
<https:/notifications/unsubscribe-auth/AGPH_UMbduLGdRaTH_VxD6MQ4PtlTmO6ks5vdj89gaJpZM4bDNFW>
.
|
|
You would need to set the I have no way to see if this works, so you will need to play around with it. Hopefully, someone like @gauravtiwari can correct me if this is the wrong approach. // webpack/environment.js
const { environment } = require('@rails/webpacker');
let sass = environment.loaders.get('sass');
sass.options = {
...sass.options, // don't overwrite existing options
includePaths: [
join(dirname(module.filename), 'node_modules')
]
};
environment.loaders.sass = sass;Adapted from: https:/rails/webpacker/blob/master/docs/css.md#resolve-url-loader |
|
Since However this does not work: |
|
Can we get some input from the Rails team on this? |
|
@gauravtiwari ping |
|
Your structure is wrong:
Plainly: you don't want |
|
This is the best I could come up with was: output: |
|
@jakeNiemiec If I try applying your version with small fixes ie. I get: |
|
I'm probably being a pain in the ass but people making those moudules are not making it any easier to use them. |
|
@Quintasan I stopped using webpackER for this very reason. I don't know why we need to programmatically build a config. Looking at your error: All you need is a ~ to indicate that the file is in |
|
At this point, you could just replace it with exactly what you need: environment.loaders.get("sass").use[3] = {
loader: "sass-loader",
options: {
sourceMap: true,
includePaths: [
join(dirname(module.filename), 'node_modules')
]
}
} |
|
@jakeNiemiec yeah, still doesn't work lol yield |
|
Above I saw: The path is relative to where your run If none of that works, you could use a dist/pre-compiled version of the @Material repo into your source. Not pretty, but I suspect that webpacker is just not up for this edge case. Edit: Seems like most frameworks need custom directions to use this lib. A PR might be needed to deal with this in a way like: https:/material-components/material-components-web-react/blob/master/README.md#step-3-using-sass. 05/07/19 edit: @aried3r Nice spread finesse. |
|
@jakeNiemiec it worked, my bad there, thanks! I still find it amusing how using an npm-distributed component is an edge-case though :D |
|
Hey, thanks for your work, I was facing the exact same issue. This is a bit more involved, but doesn't hardcode const sassLoaderIndex = environment.loaders
.get("sass")
.use.findIndex(el => el.loader === "sass-loader")
let sassLoader = environment.loaders.get("sass").use[sassLoaderIndex]
sassLoader = {
...sassLoader,
options: {
...sassLoader.options,
includePaths: ["./node_modules"],
},
}
environment.loaders.get("sass").use[sassLoaderIndex] = sassLoader |
|
@aried3r your example does work but I guess it doesn't show the complete file as I don't see neither I've added to my code to make it work, but it might be best for people coming to this thread to see the complete example. @aried3r Could you please update your code? Thanks |
|
This works for me: environment.loaders.get('sass').use.find(item => item.loader === 'sass-loader').options.includePaths = ['node_modules'] |
|
#̶ ̶A̶d̶d̶i̶t̶i̶o̶n̶a̶l̶ ̶p̶a̶t̶h̶s̶ ̶w̶e̶b̶p̶a̶c̶k̶ ̶s̶h̶o̶u̶l̶d̶ ̶l̶o̶o̶k̶u̶p̶ ̶m̶o̶d̶u̶l̶e̶s̶
#̶ ̶[̶'̶a̶p̶p̶/̶a̶s̶s̶e̶t̶s̶'̶,̶ ̶'̶e̶n̶g̶i̶n̶e̶/̶f̶o̶o̶/̶a̶p̶p̶/̶a̶s̶s̶e̶t̶s̶'̶]̶
r̶e̶s̶o̶l̶v̶e̶d̶_̶p̶a̶t̶h̶s̶:̶ ̶[̶'̶.̶/̶n̶o̶d̶e̶_̶m̶o̶d̶u̶l̶e̶s̶'̶]̶Edit: After testing this, setting To all others who still need to use the workaround described above, webpacker 5.0.1 ships with sass-loader 8, which means the config object changed, and Probably (untested) something like this (this would probably overwrite // config/webpack/environment.js
let sassLoader = environment.loaders
.get("sass")
.use.find(item => item.loader === 'sass-loader')
sassLoader = {
...sassLoader,
options: {
...sassLoader.options,
sassOptions: {
...sassLoader.options.sassOptions,
includePaths: ["./node_modules"],
},
},
} |
|
Here is my take on the issue: |
|
I have the same problem, nothing works from here |
|
Hey, I have a problem with nested JS. In development
But when precompiling iin staging/production t does nothing without giving an error. Anyone else seeing this? Bug? |
|
Is this still an issue? Feel free to close the issue if isn't |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When loading a dependancy that's external you prefix it with a tilde e.g.
@import "~external-package/external-file";However if that external package also has external dependancies you will get Module build failed errors when compiling the pack.
To fix this you have to manually go into the package and prefix all additional dependancies with the tilde so that they can be found and imported... which is obviously not a solution.
For example I might have:
@import "~@material/typography/mdc-typography";And then I've had to go into
node_modules/@material/typography/_mixins.scssand do this:Apparently this was an issue with the sass-loader and scoped modules/dependancies: material-components/material-components-web#981 and webpack-contrib/sass-loader#466
They mention in the ticket to add includePaths to sass-loader to load the modules:
which in Webpacker I'm assuming is the same as adding
resolved_paths: ['node_modules']towebpacker.ymlso that Webpacker knows where to look...But this does not fix the issue without doing the manual hack job above to prefix everything...
Does Webpacker have a solution for this?
The text was updated successfully, but these errors were encountered: