-
Notifications
You must be signed in to change notification settings - Fork 73
After rename a sourcemap, sourceMappingURL should be updated with the new map file #62
Comments
I am encountering this issue as well. |
Me too. |
I actually fixed this in #67. Waiting for a merge. |
@ncthis nice work. Lets get this merged! @sindresorhus (not picking on you just, you're the last person who made a commit to this repo 💃) |
Any suggestions on the best work around for this? I pulled down @ncthis code, and it works. Unfortunately if someone else on my team wants to build our project, their npm will pull down, the version that doesn't rename the map. |
@stroebele My suggestion in this case (temporal fix easy to disable): module.exports = function (grunt) {
grunt.registerMultiTask('afterFilerev', 'Fix sourcemaps paths after filerev', function () {
var files = grunt.file.expand({
filter: 'isFile'
}, this.data.src);
// replace sourcemaps with revv name
eachAsync(files, function (el, i, next) {
var content = grunt.file.read(el);
grunt.file.write(
el,
content.replace(
/sourceMappingURL=([^\s]+)/g,
'sourceMappingURL=' + path.basename(el) + '.map'
)
);
next();
}, this.async());
});
}; And I just configured this task to be run after filerev. |
This is really annoying. I think it is best to switch back to 2.0.0 |
+1 |
Does sourceMappingURL point to the actual map file or the source file? Are the sourcemaps gettings revisioned as well? |
The Source-map file are rev'd with the minified .js file but the |
I kind of feel like sourcemaps should not be revisioned ... because they should not be in production code. Debugging should happen on dev code. The system that converts from dev to production should not be introducing new errors (if it does then that needs to be patched). Having source maps in production just sends unneeded extra data |
There are cases when you might need maps to catch unforeseen production bugs. A project I was working on needed it so services like bugsnag could work. |
waiting for code updates before #67 can be merged. |
Has this been merged yet? |
Please get this merged in soon. Unfortunately, you can't even exclude sourcemaps from getting rev'ed because of the "feature" to ensure they are rev'ed in sync with the source files. Sourcemaps are valuable in production and are only downloaded when dev-tools are open, so there should be no reason for them not to be included. With the current state of this plugin, sourcemaps leave dev-tools in a broken state. |
@david-gang going back to 2.0.0 doesn't seem to change the bahaviour |
@PedroEsperanca . It worked for me. I traced back when the change of the source map was made. I think it was made around 2.1, so i got back to 2 |
Updated PR (#79) that can be merged. |
It appears that this is not quite fully fixed. I've pulled down the updated version by pointing npm directly at Running the task, I get the following failure message: Please let me know if there is something that I missed or if there is additional information that I could provide to dig deeper into this. |
Ah, I think the fix was only added for js files. Let me take a look... |
Hey all,
After run
filerev
with sourceMaps for JS and CSS, I found with there is none update of thesourceMappingURL
pointing to the new.map
file.Current behavior:
1- a.js with sourceMappingURL=a.js.map
2- run filerev
3- a.12345678.js with sourceMappingURL=a.js.map
Expected behavior:
1- a.js with sourceMappingURL=a.js.map
2- run filerev
3- a.12345678.js with sourceMappingURL=a.12345678.js.map
Is there something complicated behind this issue?
Thanks!
The text was updated successfully, but these errors were encountered: