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

Add option to embed code to sourcemaps #132

Open
RaveNoX opened this issue Feb 12, 2014 · 12 comments
Open

Add option to embed code to sourcemaps #132

RaveNoX opened this issue Feb 12, 2014 · 12 comments

Comments

@RaveNoX
Copy link

RaveNoX commented Feb 12, 2014

It would be great to add option to embed Coffee code to source map, to not deploy original file to server

@jamesplease
Copy link
Member

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.

@tkellen
Copy link
Member

tkellen commented Feb 12, 2014

@jmeas / @mzgoddard
I'm just going to keep saying it--thank you for tackling these issues!!

@vladikoff
Copy link
Member

@jmeas is this going to be a module? i.e grunt-lib-sourcemap?

@jamesplease
Copy link
Member

@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.

@mzgoddard
Copy link

@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.

@juriejan
Copy link

+1

@juriejan
Copy link

@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.

@jamesplease
Copy link
Member

@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:

  1. Copy the source files to a directory accessible by the web server
  2. Use those copied files as the src of this task
  3. 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.

@juriejan
Copy link

@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.

@jamesplease
Copy link
Member

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.

@juriejan
Copy link

Sounds good. I can't see myself using link in the foreseeable future.

@justinanastos
Copy link

@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.

This was referenced Dec 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants