grunt-contrib-coffee
grunt-contrib-coffee copied to clipboard
Add option to embed code to sourcemaps
It would be great to add option to embed Coffee code to source map, to not deploy original file to server
I completely agree, and have this on my to-do list already.
Actually, @mzgoddard and I spent awhile thinking about what we thought are a complete set of source map options for the grunt-contrib suite; you can view what we came up with here. If you feel like making a PR that adheres to those options it'd definitely be merged. Otherwise this should be done in a few weeks.
@jmeas / @mzgoddard I'm just going to keep saying it--thank you for tackling these issues!!
@jmeas is this going to be a module? i.e grunt-lib-sourcemap
?
@vladikoff, yeah, as I've been thinking about this the past few days I thought it would make sense to pull out the shared bits in a module. But I have none of the details of what that module would look like worked out. @mzgoddard, we should meet again to discuss that possibility – and, of course, anyone else can join if you're interested.
@jmeas, yup. I've been thinking about it too. I think it'd likely hold any work to normalize source map output by dependent libraries, such as embedding source content if the dependent library doesn't have an option to do that itself.
+1
@jmeas, I think you'll probably need to include an option for specifying the root URL to the original source files if one is making use of the link
source map style.
@juriejan, the library will generate the path from the map to the source files, leaving it up to the developer to make sure that those source files are accessible by the web server. The workflow for making this work is:
- Copy the source files to a directory accessible by the web server
- Use those copied files as the
src
of this task - Profit
This gives us that functionality you're describing without introducing a new option. We're thinking most users won't care about using the link
style though, given that embed is the default and, as far as I can tell, offers all the same benefits with less hassle.
@jmeas, I see what you mean, but I still think there might be times that the serving of source and map files won't be that straight forward. What if for some reason files are compiled and source maps are generated before the files are in the location where they are to be served from?
I won't mind if you carry on without an extra option since I can't see myself using the link
style anytime soon.
I agree that the link
style won't be used too often as embedding is just so much simpler. I almost feel that one should consider dropping link
support completely, but I guess there are some edge cases that it might still be useful.
What if for some reason files are compiled and source maps are generated before the files are in the location where they are to be served from?
Using embed will handle this case, and as your second paragraph suggests I imagine most people will want to use embed. The difficulties with using link
are a consequence of having a simpler set of options. If a really compelling use case comes up to support link
in a more substantial way it could be done pretty easily, but for now we're assuming people won't care about it.
Sounds good. I can't see myself using link
in the foreseeable future.
@jmeas Thank you for working on this. It's awesome to think "man, this would be a great idea..." only to find out it's already in progress. I'm looking forward to this.