I am using the following setup:
Mac OSX El capitan
angular-cli v1.0.0-beta.11-webpack.8, branch: master
node 6.5.0
os: darwin x64
Using Sass
This might not be a bug with angular-cli, perhaps it is a limitation with angular2 but I am looking for anyone who's managed to solve this. I cannot get the sass to be source mapped. I want to inspect the CSS and see where a particular value is being set.
Personally, I am trying to work out how to edit the setup so I can do this locally. I am not too concerned in editing the webpack config, this is only going to be an issue in development, not production. But thinking globally, I think this should just work for anyone using angular-cli.
I have tried adding the source map commands here to webpack-build-common but no luck... I still see only the css in the head and nothing external.
I also saw another user trying something here with LESS, maybe I can do similar...
https://github.com/angular/angular-cli/issues/1656#issuecomment-240983105
I also found this issue in the angular project but it appears to be fixed now.
This issue appears whether I use css, sass and whether I change ViewEncapsulation within the component or not.
I am not at all familiar with webpack and only angular 1.5 so please forgive me. Any help appreciated :)
Edit: here is my project setup
I managed to solve my issue by editing the webpack-build-common.ts
file to have
{
exclude: styles,
test: /\.scss$|\.sass$/,
loaders: ["raw-loader", 'postcss-loader', 'sass-loader', "sass?sourceMap"]
}
and
{
include: styles,
test: /\.scss$|\.sass$/,
loaders: ["style", "css?sourceMap", "sass?sourceMap"]
}
instead of the previous loaders for those .scss tests. This seems to be OK for development so far.
@retallicka good job tracking it down!
@TheLarkInn is this something we should add to our config? I'm all for it if it helps users, and doesn't affect prod builds.
I'm using angular-cli 1.0.0-beta.16.
What I needed for my project was to be able to just track down CSS issues during development. Thanks to the hint from @retallicka, I edited webpack-build-common.js
and changed
{
include: styles,
test: /\.css$/,
loaders: ['style-loader', 'css-loader', 'postcss-loader']
}
to
{
include: styles,
test: /\.css$/,
loaders: ['style-loader', 'css-loader?sourceMap', 'postcss-loader']
}
This seems to be working so far. But an option to enable/disable this from the CLI would be great.
I presume that I will have to remove this change before building for production--is that right?
I also had to update to angular-cli: 1.0.0-beta.18 as 17 would generate an error when adding ?sourceMap.
However, I still can't get the source-maps to map correctly, the source maps are only pointing to the parent selector.
Seen Here: #2826
@retallicka Are the SourceMaps pointing to the correct selector for you? If so can you post your webpack config file settings.
Thanks
Hi,
I'm using 1.0.0-beta.20-4.
I was hoping that beta.20-4 would solve this issue but after updating from beta.19 the styles have lost the sourceMap and it's impossible to inspect in the browser, just the same as before applying the changes suggested by @retallicka but now I think that webpack-build-common.js has changed a lot and is not possible to apply this temporal solution again.
Any workaround please? Thanks a lot!
Reopening to investigate.
@filipesilva @TheLarkInn Please fixing this is quite important. The referenced PR fixes it:
https://github.com/angular/angular-cli/pull/3272
Could you take a look and merge it, please? Thanks!
Thanks also @mikejpeters !
I also have this problem in 1.0.0-beta.24
, repo'd by doing聽ng new test
, putting some css in styles.css and doing ng serve
and then navigating to http://localhost:4200/styles.bundle.map results in
{"version":3,"sources":[],"names":[],"mappings":"","file":"styles.bundle.css","sourceRoot":""}
the js bundles seem to work as expected.
(i'm very new to angular 2 and angular cli so I might have missed a needed setting though)
It seems there might be something missing in https://github.com/angular/angular-cli/pull/3402 then. Will have to investigate.
@filipesilva hello, whats the current state?
cli-beta.26 stilll sourcemaps:
http://localhost:4200/styles.bundle.map
//cli.json
styles: [
"style.scss"
]
ng serve --extract-css=true
@filipesilva
quick fix that works for me:
https://github.com/angular/angular-cli/pull/4219
@marekstabla I tried your fix but don't see any difference with a .css
file. How did you test it was working?
I tried fiddling a bit more and it seems to work with a sourceMap
(no s
at the end) query. Will try to put up a PR with a fix and tests.
@filipesilva
difference is inside map file (http://localhost:4200/styles.bundle.map) - looks low now it's properly generated
it works for me with s
at the end - anyway let me know if that works for you :)
edit
double checked - it works only without s
. Sorry!
https://github.com/webpack/css-loader seems to be the true origin of this problem, as we use LoaderOptionsPlugin
to pass in the loader options.
Agreed. Looks like it ignores sourceMap option. Anyway others can use this as a workaround for now.
@filipesilva updated https://github.com/angular/angular-cli/pull/4219
Now it depends on buildOptions.
At least it works for now since LoaderOptionsPlugin fails with css-loader
Added a more complete fix in #4222, including tests so we can be sure there are no regressions.
@filipesilva: It seems #4219 breaks CSS with sourcemaps enabled in some cases. Seems to be an issue with sourcemaps and css-loader when using urls with relative paths: https://github.com/webpack-contrib/css-loader/issues/232. Any ideas?
EDIT: Enabling extract CSS (e.g., ng serve --ec=true
) solves this issue
It's not solution - it's workaround. Anyway I can confirm this bug. Perhaps we could enable css extract by default for dev mode? @filipesilva
@marekstabla hell no please. its slow. Super slow in compare with normal mode. LIke 8sec and 36sec
Argh that's a really bad bug. The workaround they mention isn't very good either because it'd break on a number of scenario. I'm following that issue to see if there's a fix.
Meanwhile the best I can say is that turning off sourcemaps will fix it.
@filipesilva: IMO, that's not really a good solution either, unfortunately. Debugging TypeScript without sourcemaps is not ideal.
The current options that I can think of to solve this for our development environment are the following:
Another way to mitigate this in the interim would be to treat sourcemaps for styles and TypeScript separately configuration-wise. That way the user could decide to disable sourcemaps for styles if necessary. Obviously not ideal, but not sure what else we could do here. Thoughts?
@brendenpalmer @marekstabla @montella1507 I've opened a new issue to track this problem: https://github.com/angular/angular-cli/issues/4273
I don't have a good solution for now. Will try and see if the original problem can be addressed.
SCSS source maps have never worked for me in versions 1.0.0-beta.19 to the latest 1.0.0-beta.31. I don't know what I'm missing - all styles in Google Chrome inspector show as inlined. It's frustrating and I've been following these source map issue threads for months.
Currently I'm running 1.0.0-beta.31 and tried upgraded and fresh instances on macOS and Google Chrome - latest versions.
Relevant config is:
"styles": [
"styles/app.scss"
],
...
"defaults": {
"styleExt": "scss",
"prefixInterfaces": false,
"inline": {
"style": false,
"template": false
},
"spec": {
"class": false,
"component": true,
"directive": true,
"module": false,
"pipe": true,
"service": true
}
}
@cjmosure please run your project again using the flag --ec=true
i.e.: ng serve --ec=true
.
I can't remember where I read a suggestion to use this flag, but it does exactly what we need on chrome debugging.
@alfupe you are a boss sir, that worked for me.
@cjmosure :-) I'm glad to read that this worked for you also.
@cjmosure @alfupe
I've got same config like cjmosure. Running ng serve --extract-css=true does not solve the problem for me =/ Any suggestions? Do I need a special folder structure? Do I need to list every single SCSS in angular-cli.json?
@kaynz did you updated the cli from a former version? if you create a fresh project using the latest cli version the problem persists?
Regarding folder structure, I don't think the problem is there but anyhow I don't use the styles.scss in src/. My main .scss file is in src/assets/main.scss so my angular-cli.json is:
"styles": [
"assets/scss/main.scss"
]
In my case using the --ec=true
(or --extract-css=true
) flag works fine for the global scss but the component's scss still gets inlined and Chrome dev tools points to <style>...</style>
tags in the page header, but i think it's a normal behaviour.
One last thing I would try is completely delete node_modules and make a npm install
to check possible inconsistencies in your dependencies.
I'm in cli beta30 and this is working for me since at least beta 28. Some of my package.json
dependencies regarding are:
"dependencies": {
"@angular/common": "^2.4.5",
"@angular/compiler": "^2.4.5",
"@angular/core": "^2.4.5",
"@angular/forms": "^2.4.5",
"@angular/http": "^2.4.5",
"@angular/platform-browser": "^2.4.5",
"@angular/platform-browser-dynamic": "^2.4.5",
"@angular/router": "^3.4.5",
"@ngrx/core": "^1.2.0",
"@ngrx/store": "^2.2.1",
"core-js": "^2.4.1",
...
"ts-helpers": "^1.1.1",
"zone.js": "^0.7.6"
},
"devDependencies": {
"@angular/compiler-cli": "^2.3.1",
"@types/bootstrap": "^3.3.32",
"@types/core-js": "^0.9.35",
"@types/jasmine": "2.5.38",
"@types/jquery": "^2.0.39",
"@types/node": "^6.0.62",
"@angular/cli": "^1.0.0-beta.30",
...
"ts-node": "1.2.1",
"tslint": "^4.3.0",
"typescript": "^2.1.5"
}
@alfupe Thank you.
I did not update from a former version. Fresh install, fresh node_modules.
Yes, you're right. --extract-css=true works for the global scss.
But how do I debug scss files used in the components with
styleUrls: ['../styles/header.component.scss'],
Or should I import all my scss files in the global styles.scss and remove component styles?
@kaynz it depends, I style the entire application most of the time in global .scss. 95% of my styles are there. I use component's scss only when those styles are not going to be shared between components, so (for me) if I can't debug those inlined styles is generally a minor problem among other things because I know very quickly where this css rules are and I edit them directly in the IDE instead of testing in Chrome.
Being said that, it would be very nice also to have sourcemaps for the component's styles.
@alfupe Looks like this was possible earlier... https://github.com/angular/angular/issues/9664 ?
@kaynz good question. To be honest I don't know if the problem comes from angular or from angular-cli since the change to webpack...
Has there been any movement on component scss sourcemaps with the cli?
When you type ng serve by default angular cli doesn't include sourcemaps files for css files but you can include it by typing this command
ng serve -sm -ec
or
ng serve --sourcemap --extractCss
I use Angular Cli -v 1.0.3, and More information - Angular CLI special cases
@Koziuk-S As said here it only works for global scss, not the component scss files
I am also looking for a solution right now
The same seems to be true of Less. I'm compiling my Less stylesheets using webpack with @ngtools/webpack and source map info is not being written to the generated component styles. I'm not using the Angular CLI. Global styles are working just fine, but they're not compiled by any of the Angular-specific tools.
FWIW, the method from @Koziuk-S works great, but for some reason Safari (both 10.1.1 and TP30) do not see the source maps and still points to styles.bundle.css
for all rules.
UPDATE: Also broken in TP 32/Safari 11.
However, Chrome is working perfectly with the same files, same build etc.
Can anyone provide any feedback as to whether it's possible to have source maps available for component scss? If so, is there an ETA?
I can't believe we are still having this problem :(
This issue(and several others on sourcemaps) seem closed. Perhaps someone should create a detailed issue with reference to this an the other dead threads?
Is there any kind of a workaround for this?
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._
Most helpful comment
Is there any kind of a workaround for this?