-
Notifications
You must be signed in to change notification settings - Fork 12k
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(new): include app level import paths for style preprocessors #3724
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
I signed it! |
CLAs look good, thanks! |
There's already an in progress PR (#2747) for this (with a discuss tag attached and a potentially blocking issue). |
Yes, except I was looking to move things along. I have referenced the aforementioned PR (#2747) in my comment above. Also in this implementation it provides support for the three major preprocessors that angular-cli supports and not just sass as in the previous PR. And this PR provides an entrypoint through the angular-cli configuration to configure extra paths for any of the preprocessors. The currently active PR is an implementation on a much stale commit on angular-cli. If anything this can be used as material for the discussion or give pointers for an up to date solution. That being said... I think there's better ways to handle the loader options (I moved prod and dev into common for the timebeing because of the autoprefixer configuration, seems more DRY). I also think there's a better way to organize the specific logic required per loader to make this happen instead of having a block of code for this specific handling. |
@admosity you're going to have to squash the commits. Might as well get that out of the way. |
49d91c8
to
8dd3456
Compare
Updated to latest master and squashed. I'm a bit slow with the upkeep right now. Currently on vacation. |
406d048
to
3dbf5d2
Compare
73c6eea
to
3dbf5d2
Compare
- fixed linter errors - re-run build-config-interface - refactored variable names to preprocessors instead of style - use cliConfig to determine preprocessor for project
3dbf5d2
to
446564d
Compare
Would this fix sass It's throwing this
|
@admosity are you absolutely sure this works for stylus? Because I've been working on this issue as well and as far as I can tell, stylus needs the path options in the loader query and less doesn't work at all. @fxck I have no idea why it wouldn't work with AoT Plugin. Are you using it separately, with a config that supports paths for sass? |
@filipesilva all I did was {
test: /\.scss$/,
use: [
'to-string-loader',
'css-loader',
'sass-loader',
'postcss-loader'
],
},
/// ----
new LoaderOptionsPlugin({
debug: true,
options: {
sassLoader: function () {
return {
includePaths: [ root('src/app/styles') ]
}
}
}
}), and then @import 'variables'; it works fine in JIT, throws
when I try to build with AOT ...when I remove the
new AotPlugin({
tsConfigPath: 'tsconfig.json',
mainPath: root('src/main.browser.ts'),
})); |
Superseded by #4003 |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Fixes #2747 and #3683.
Added a possible solution for sass, less, and I think stylus? (uses
paths
instead ofincludePaths
).Added a new configuration property to apps
webpackStyleLoaderOptions
that only supports one property at the momentincludePaths
.Sample Config:
Other notable changes:
Removed the plugin
webpack.LoaderOptionsPlugin
definition in the prod build and added a condition in common for including the css stripping plugin. Seems more DRY.Updated the schema, but it looks like it generated differently for:
Not sure if that's going to be an issue.