refactor: support force disabling sourcemaps and setting sourceRoot#153
refactor: support force disabling sourcemaps and setting sourceRoot#153kherock wants to merge 1 commit intowebpack:masterfrom
Conversation
|
|
b3b11e6 to
3e961e3
Compare
|
@rockmacaca Can you please Close and reopen the PR to trigger the CLA Bot and rebase against current master ? 😛 |
|
Before anyone considers / begins to review this pull request, it needs to be rebased with current master and it has to be |
|
I'll rebase when I have a chance later this week! |
20ba6b3 to
5e9b5c2
Compare
|
@michael-ciniawsky this is ready to be looked at! Sorry I didn't mention it earlier |
michael-ciniawsky
left a comment
There was a problem hiding this comment.
@rockmacaca 👍 See the comment for discussion && Docs and Tests then 😛
| function addStyle(obj, options) { | ||
| var styleElement, update, remove; | ||
|
|
||
| if (obj.sourceMap && typeof options.sourceRoot === "string") { |
There was a problem hiding this comment.
@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
There was a problem hiding this comment.
Yeah, I would rather go with this than to add yet another field to the API. Better reuse this time.
There was a problem hiding this comment.
if (obj.sourceMap && !obj.sourceMap.sourceRoot.match(/webpack:\/\/\//) {
obj.sourceMap.sourceRoot = 'webpack:///' + obj.sourceMap.sourceRoot
}There was a problem hiding this comment.
@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 😛
joshwiens
left a comment
There was a problem hiding this comment.
Needs docs & tests but beyond that and the change in the other comment should be g2g
|
@rockmacaca According to Tobias |
|
@rockmacaca friendly ping 😛 |
|
Sorry, I've been putting this off for a bit too long - Yes, sass-loader --> postcss-loader --> raw-loader (modified with sourcemap support) --> style-loader For production builds, I have style-loader swapped with |
|
Agreeing upon that and |
|
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 |
michael-ciniawsky
left a comment
There was a problem hiding this comment.
@rockmacaca Please see the comment :)
| function addStyle(obj, options) { | ||
| var styleElement, update, remove; | ||
|
|
||
| if (obj.sourceMap && typeof options.sourceRoot === "string") { |
There was a problem hiding this comment.
if (obj.sourceMap && !obj.sourceMap.sourceRoot.match(/webpack:\/\/\//) {
obj.sourceMap.sourceRoot = 'webpack:///' + obj.sourceMap.sourceRoot
}| function addStyle(obj, options) { | ||
| var styleElement, update, remove; | ||
|
|
||
| if (obj.sourceMap && typeof options.sourceRoot === "string") { |
There was a problem hiding this comment.
@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 😛
|
@rockmacaca How should we proceed with this ? |
|
I'll let you know in a bit, I think I'm just going to remove the boolean I also want to investigate how it interacts with |
|
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 😛 |
|
Ok, I just realized what that PR does and it completely fixes the reason I added the |
|
Sry but I have to decline this, since source maps will be inlined in |
|
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? |
|
Yes |
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
sourceRootproperty 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. TheExtractTextPluginhandles these fine since the paths are set viamoduleFilenameTemplate. I could write an intermediate loader just to setsourceRoottowebpack:///, but it would be nice if I could do that throughstyle-loader's config, which is the goal of this PR.Does this PR introduce a breaking change?
Nope!