Skip to content
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

refactor: support force disabling sourcemaps and setting sourceRoot #153

Closed
wants to merge 1 commit into from

Conversation

kherock
Copy link

@kherock kherock commented Dec 1, 2016

What kind of change does this PR introduce?

feature

Summary

SourceMaps have so far been a real pain to track down the source of issues with, and the way CSS loaders handle them seem to be all over the place. Most of these stem from the sourceRoot property being set and then integrated into the actual source paths somewhere down the line. This is especially problematic if webpack isn't being run in the current working directory (as I am). As long as it's blank throughout though, things seem to work out.

However, once the maps arrive at style-loader, they have no root, and without one they get put under the (no domain) section in Chrome's Sources view. The ExtractTextPlugin handles these fine since the paths are set via moduleFilenameTemplate. I could write an intermediate loader just to set sourceRoot to webpack:///, but it would be nice if I could do that through style-loader's config, which is the goal of this PR.

Does this PR introduce a breaking change?

Nope!

@jsf-clabot
Copy link

jsf-clabot commented Dec 1, 2016

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

@michael-ciniawsky
Copy link
Member

@rockmacaca Can you please Close and reopen the PR to trigger the CLA Bot and rebase against current master ? 😛

@joshwiens
Copy link
Member

Before anyone considers / begins to review this pull request, it needs to be rebased with current master and it has to be rebase

@kherock
Copy link
Author

kherock commented Mar 15, 2017

I'll rebase when I have a chance later this week!

@kherock kherock force-pushed the master branch 2 times, most recently from 20ba6b3 to 5e9b5c2 Compare March 21, 2017 06:22
@kherock
Copy link
Author

kherock commented Mar 23, 2017

@michael-ciniawsky this is ready to be looked at! Sorry I didn't mention it earlier

Copy link
Member

@michael-ciniawsky michael-ciniawsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rockmacaca 👍 See the comment for discussion && Docs and Tests then 😛

@@ -171,12 +171,17 @@ function attachTagAttrs(element, attrs) {
function addStyle(obj, options) {
var styleElement, update, remove;

if (obj.sourceMap && typeof options.sourceRoot === "string") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rockmacaca This is not mandatory, more of a triage 😛 , but would it be a breaking change, if we change the signature of sourceMap to sourceMap: Boolean || { sourceRoot: '...' } instead of adding a new option sourceRoot ? Shouldn't be, but needs to be verified

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I would rather go with this than to add yet another field to the API. Better reuse this time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (obj.sourceMap && !obj.sourceMap.sourceRoot.match(/webpack:\/\/\//) {
  obj.sourceMap.sourceRoot = 'webpack:///' + obj.sourceMap.sourceRoot
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rockmacaca Something in that direction is what I mean by 'can we avoid adding an extra option'? 🙃 If not possible and the user needs control over this, then it can't be helped 😛

Copy link
Member

@joshwiens joshwiens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs docs & tests but beyond that and the change in the other comment should be g2g

@michael-ciniawsky
Copy link
Member

@rockmacaca According to Tobias sourceRoot should always be empty to work with webpack, could you elaborate again on why you want to modify it ? 😛

@michael-ciniawsky michael-ciniawsky changed the title Support force disabling sourcemaps and setting sourceRoot refactor: support force disabling sourcemaps and setting sourceRoot Apr 18, 2017
@michael-ciniawsky michael-ciniawsky moved this from Feature to Refactor in Dashboard Apr 18, 2017
@michael-ciniawsky
Copy link
Member

@rockmacaca friendly ping 😛

@kherock
Copy link
Author

kherock commented Apr 25, 2017

Sorry, I've been putting this off for a bit too long -

Yes, sourceRoot is expected to be empty as maps get passed through webpack. The last time I checked, I believe css-loader typically used in conjunction will take care of setting the webpack:// prefix on maps, but I am choosing to use my own set of loaders. If you're curious what it is, it's just

sass-loader --> postcss-loader --> raw-loader (modified with sourcemap support) --> style-loader

For production builds, I have style-loader swapped with ExtractTextPlugin (which doesn't have the problem this PR addresses since it uses the moduleFilenameTemplate function). As the paths shouldn't be prefixed with anything by the time they arrive at style-loader, they appear in the (no domain) section. I'm making the PR here since it shouldn't be the responsibility of any intermediate loader to correctly set the prefix.

@michael-ciniawsky
Copy link
Member

Agreeing upon that and postcss-loader v2.0.0 (especially for Angular folks) will export a module directly (no raw-loader) in the near future, could you post an usage example of how you would to use this feature purposed in the PR and could we fix it without introducing an extra option for it (based on a pattern etc)? 😛

@kherock
Copy link
Author

kherock commented Apr 25, 2017

Sure. This is a rule I have for my plain CSS files:

{ use: ['style-loader?sourceRoot=webpack:///', 'css-raw-loader'], include: path.resolve(__dirname, './app') }

css-raw-loader is literally just a copy of raw-loader but it attaches a sourcemap.

I like being able to just use the inline query string format, but your suggestion of having a signature of
sourceMap: Boolean || { sourceRoot: '...' } would also work. To be honest, the original sourceMap option I added should probably be removed entirely. I only added that while I was still figuring out how webpack's loader lifecycle worked. Since the entire sourcemap is still included in the bundle and all it is accomplishing is hiding it from the browser's sources inspector, it isn't really useful.

Copy link
Member

@michael-ciniawsky michael-ciniawsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rockmacaca Please see the comment :)

@@ -171,12 +171,17 @@ function attachTagAttrs(element, attrs) {
function addStyle(obj, options) {
var styleElement, update, remove;

if (obj.sourceMap && typeof options.sourceRoot === "string") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if (obj.sourceMap && !obj.sourceMap.sourceRoot.match(/webpack:\/\/\//) {
  obj.sourceMap.sourceRoot = 'webpack:///' + obj.sourceMap.sourceRoot
}

@@ -171,12 +171,17 @@ function attachTagAttrs(element, attrs) {
function addStyle(obj, options) {
var styleElement, update, remove;

if (obj.sourceMap && typeof options.sourceRoot === "string") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rockmacaca Something in that direction is what I mean by 'can we avoid adding an extra option'? 🙃 If not possible and the user needs control over this, then it can't be helped 😛

@michael-ciniawsky
Copy link
Member

@rockmacaca How should we proceed with this ?

@kherock
Copy link
Author

kherock commented Apr 28, 2017

I'll let you know in a bit, I think I'm just going to remove the boolean sourceMap option. This PR is pretty tiny so I can rebase on top of #219 if that's getting merged soon.

I also want to investigate how it interacts with css-loader so I could possibly set some default values without breaking existing setups.

@michael-ciniawsky
Copy link
Member

Yep no rush, so when #219 lands, this will still be a needed? Tbh I haven't had much time recently to take a deeper look at it, so sry in advance if this is bit naively asked 😛

@kherock
Copy link
Author

kherock commented Apr 28, 2017

Ok, I just realized what that PR does and it completely fixes the reason I added the sourceMap option, since I use relative paths in my CSS. I still want to be able to customize sourceRoot though. I'll amend this sometime soon and I'll just resolve any conflict that arises once 219 is taken care of.

@michael-ciniawsky
Copy link
Member

Sry but I have to decline this, since source maps will be inlined in style-loader >= v1.0.0, this PR isn't needed/won't work in v1.0.0.

@kherock
Copy link
Author

kherock commented Jan 8, 2018

That's all right, I haven't been too concerned about it. It's actually pretty simple to create my own loader that handles prefixing the paths.

In the meantime, are there plans to publish a beta or RC for v1.0 to npm anytime soon?

@michael-ciniawsky
Copy link
Member

Yes v1.0.0-alpha will be released in ~1-2 days, maybe today if nothing else pops up on my schedule :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Dashboard
Refactor
Development

Successfully merging this pull request may close these issues.

None yet

5 participants