-
Notifications
You must be signed in to change notification settings - Fork 339
Supporting source maps #220
Comments
hey guys, any news on this issue? that's exactly what we need now - to generate source maps automatically for a few bundles we have. I'll be happy to beta test what you have. Serge |
See #230 for a PR implementing something similar to what I've described here. |
Has there been any progress with this issue? Feels like many people could benefit from this 😄 |
@ianmurrays I may be wrong but I don't think any progress have been done on this issue. But with the current development it should be easier to implement this feature. |
I got source maps working just fine with usemin using the
concat will generated source maps in |
@jgogstad thank you for coming back with a solution. Will add it to the readme. |
@jgogstad Why not just
Is not it the same? Difference is that source map files will be generated by uglify, not by concat. I actually have another problem. I need both minified and not minified versions of file in dist folder. grunt-uglify supports this, but I do not know how to setup grunt-usemin to make |
@DMITRY9999 it is not quite the same, but it might solve your problem and save you some build time. grunt-usemin will transform the original source code twice, first combine all your sources into a single file (usually you'll configure it to create one for external source code and one for your source code, but that's beside the point), second minify and uglify that output. So if you only need to get back from the minified/uglified code, then yes, generating source maps with just uglify is what you need. If you want to get all the way back to the original files, then you need to go through two source maps, and thus the concat plugin need to generate one as well. Fortunately uglify has an option for using another source map as a starting point, that's the |
Newbie question here. Seems like @DMITRY9999 solution works and has now made it so that the source files are at least displayed when I use Firefox. Now the issue I have is that the files are not where its looking for it since there are only the files in the dist folder. How does one get around that? Do you have to copy all the source scripts as well? To explain a little more I have the folowing in my developer tools: My app.js file is mapped there but its looking for it in the absolute path from the server root. If I want it to actually find the files and therefore be able to use them would that mean I need to copy over all the non-minified scripts across to the "dist" folder as part of the build? Update: If I do in fact copy those files into the location the screen shot is looking for it still says "error loading source" in Firefox.. Any ideas? Thanks a lot. |
Configuring Should this issue be closed? |
@jgogstad Solution worked awesome for me! 😃 |
The solution proposed by @jgogstad worked like a charm. After hours struggling trying I finally find out the correct way to handle this. I believe this is quite an important configuration (almost all DEVs work with sourcemaps). @stephanebachelier in some comments above you committed to update the docs. However I haven't seen the README nor the documentation updated (i just found this thread by chance). Am I missing somethings? I'm asking this just for helping other people in the same situation. Thank you! |
There is another issue on source maps, #30, but this is a more general solution I've been working on to support source maps. I posted a separate issue because it requires pretty substantial changes to the code (that will be backwards-compatible in most cases) than what were proposed in the other issue.
Change 1: Each block gets its own target
Right now, useminPrepare populates the
generated
target for each block. This prevents you from generating separate source maps for your blocks (see this comment). Accordingly, the first change is giving each block its own unique target. I simply made the name of the target thedest
of the block. So instead ofgenerated
you might havebuild/js/script.min.js
as the target name.This would mostly be backwards-compatible. If people just run their tasks without specifying the target, there will be no difference. It would break anyone who sets the grunt task to reference, say,
uglify:generated
.Change 2: Set a
map
property for the blockAn additional parameter could be set at the start of a block:
map
. If it's present, it could do one of two things:Some issues:
uglify
requires a hacky fix to support the type of project structure that usemin requires. If mapping is built into usemin, it would need to utilize this for the time being.Based on this, maybe it'd be worthwhile to simply allow for a
map
variable that can be picked up in your steps.Change 3: See #219
I've already programmed most of this up if you'd like me to make a pull request.
The text was updated successfully, but these errors were encountered: