Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

Could you please configure publicPathas per the css-loader's docs to ensure source maps work correctly?

@mareksuscak I'm honestly not sure what you mean. I've never used publicPath and haven't had any issues with css-loader's sourceMaps. I also don't see a documented example.

I did a quick search through the css-loader codebase and couldn't find any references to publicPath either. Could you help me out?

Hm, how come? My link is pointing directly to the subsection where it's mentioned. See the attached screenshot with a red rectangle that highlights the particular subsection.

It is also noted in the SurviveJS guide. See the pic below.

Not sure if that has or hasn't been fixed.

I see where it's mentioned - I've just never seen an example in the wild
(due to lack of necessity). But sure I'll take a look, and you can check
out this branch and verify it too?
On Tue, Sep 13, 2016 at 03:58 Marek Suscak notifications@github.com wrote:

Hm, how come? My link is pointing directly to the subsection where it's
mentioned. See the attached screenshot with a red rectangle that highlights
the particular subsection.

[image: source-maps]
https://cloud.githubusercontent.com/assets/613647/18465687/45d0223c-7998-11e6-9d9d-6a4b9346837d.png

It is also noted in the SurviveJS guide
http://survivejs.com/webpack/developing-with-webpack/enabling-sourcemaps/#sourcemaps-for-styling.
See the pic below.

[image: screen shot 2016-09-13 at 09 57 07]
https://cloud.githubusercontent.com/assets/613647/18465721/79dde5f0-7998-11e6-9248-29bd17167335.png

Not sure if that has or hasn't been fixed.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#591 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AChScZ1VzfdAyP7R7AstR1nomQUifv7Gks5qplergaJpZM4J1TDd
.

Sure, will do when I get a chance today.

As noted in Contributing.md, please include a test plan for this pull request. I don’t know how to verify that it works if you don’t tell me. 😉

I get a flash of unstyled content on Chrome 52 with this feature enabled.

I’m not sure if it’s a css-loader, browser bug, or something else, but it’s annoying and will confuse our users. Could you look into why this happens?

Another area I’d like to see addressed is the performance impact. Can you create ~200 CSS files and measure first build and rebuild performance in development with and without this change?

Apologies for the lack of response on this - I'm not really sure where to start looking for the problem here though my guess would be to start in css-loader. I don't have the OSS cycles I'd like to dedicate to this, unfortunately, so someone can feel free to take or close this.

Let’s close then as the implications are unclear.
Happy to consider a similar PR if somebody figures out what’s wrong.
cc @TheLarkInn

FOUC from style source-maps? And chrome 52 (just making sure I'm catching everything I'm reading here).

Would be curious to see where those scripts are dropped on the page when rendered.

I had some time today and here's what I've found. When you use ?sourceMap option with css-loader, instead of using style tags with inline styles, webpack injects style tags that reference the dynamically generated files (source maps likely don't work well with the inline style tags). Hence we need to load a few more files after we've already run the JavaScript part which obviously causes FOUC as the HTML has already been appended. Not sure if there's a cure for that. Production env should not be affected at all.

I remember este.js suffered from FOUC in development env too in the past. Now they use JS styles.

cc @gaearon @TheLarkInn @JaKXz

Wow, thanks for looking into it. That makes sense now.

Thank you. Just my 2 cents, I'd say the dev env FOUC is worthwhile cost for extra source map features (which are handy). Especially if not affected in production (which makes sense now also).

I'm worried that not only FOUC will be annoying, people will think it's something they did wrong, or worse, that it's React problem. These days people blame everything on React so we don't want to make it easier 😉

Lol good point!

I got CSS sourcmaps and hot reloading working by following @mareksuscak's advice of changing my css loader in the webpack config to the following:

{ test: /\.css$/, loader: 'style!css?sourceMap!postcss' },

And I can't complain about FOUC (flash of unstyled content) - so all good for development!

Hope tat may help someone here! 😎

@gaearon

Need to solve flash of unstyled content, and provide build performance measurements.

Done #3202 - Add support for CSS Sourcemaps without FOUC

Hi,

Any update about css / sass sourcemaps in development mode (npm start) ?