andrewdavey / cassette

Manages .NET web application assets (scripts, css and templates)
http://getcassette.net
MIT License
534 stars 143 forks source link

Source Map #320

Open rossmerr opened 12 years ago

rossmerr commented 12 years ago

Can we have support for Source Map?

http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

andrewdavey commented 12 years ago

Yes, but we'll need this first: http://ajaxmin.codeplex.com/workitem/18743

devert commented 11 years ago

Looks like AJAX Minifier has support for source maps now. Any news on supporting or an example on how to get this working in Cassette?

andrewdavey commented 11 years ago

No news yet. We need to figure out how source maps fit into Cassette e.g. where to cache them, how to serve them, etc.

dotnetchris commented 11 years ago

I take it nothing has ever happened with this?

johnnyreilly commented 11 years ago

Hi @dotnetchris ,

I was just wondering if your question was related my own issues with this:

http://typescript.codeplex.com/discussions/444245

Essentially I've been looking to debug TypeScript using Cassette but not getting too far at the moment... Though I can happily debug generated JS - which isn't too bad since I'm essentially just using TS to ensure I'm generating type safe JS to be honest...

andrewdavey commented 11 years ago

Source map support will need to be a Cassette v3 feature. (I don't think it can be easily bolted on to v2.)

One issue I'm stuck on right now is how to combine source maps. Let's say a bundle has three assets and some of those have associated .map files.

a.js -> a.map
b.js
c.js -> c.map

To bundle these into a single file now means needing to also combine the source maps into a single map.

Also, how do we handle multi-stage transformation? For example, compiling TypeScript into JavaScript, and then minifying that JavaScript? Ideally the source map should convert the minified JS back into TS.

I'm sure this is achievable, but I've not researched how to actually do it yet.

johnnyreilly commented 11 years ago

Hi Andrew,

I'm kind of of the opinion that this situation doesn't need catering for (controversial I know!) Or at most its a nice-to-have.

Here's my rationale: we only need source maps for debugging and in debug mode (where we do our debugging) files will be served up "in the raw" as it were. In which case there's no combined files source map use case to meet.

What do you think?

Andrew Davey notifications@github.com wrote:

Source map support will need to be a Cassette v3 feature. (I don't think it can be easily bolted on to v2.)

One issue I'm stuck on right now is how to combine source maps. Let's say a bundle has three assets and some of those have associated .map files.

a.js -> a.map b.js c.js -> c.map

To bundle these into a single file now means needing to also combine the source maps into a single map.

Also, how do we handle multi-stage transformation? For example, compiling TypeScript into JavaScript, and then minifying that JavaScript? Ideally the source map should convert the minified JS back into TS.

I'm sure this is achievable, but I've not researched how to actually do it yet.

— Reply to this email directly or view it on GitHub.

NikGovorov commented 11 years ago

I'm agree with @johnnyreilly about the need of source maps only under debug mode.

dotnetchris commented 11 years ago

Yes debug only support.

johnnyreilly commented 11 years ago

Hi Guys,

Whilst we're on the topic I thought I'd share the little I know. If you're looking for a good description of how source maps work then this article is pretty good:

http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

Or if you want to go deep then read this:

https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit?pli=1

I had assumed that Visual Studios debugging tooling would be using the Response headers mechanism, eg:

X-SourceMap: /path/to/file.js.map

However, after a little experimentation with Fiddler debugging TypeScript using the default TypeScript HTML App project it looks like VS is powered by the source mapping URL approach:

//@ sourceMappingURL=/path/to/file.js.map

So my guess is that the VS debugger would hopefully play nice with Cassette if Cassette performed the following actions when serving in debug mode:

  1. Cassette would need to amend the sourceMappingURL property of the generated JavaScript to point to the location of where Cassette was hosting the .js.map file.
  2. Cassette would need to amend the .js.map files file / and sources properties to reflect the location of where Cassette was hosting the .js and .ts files

So it's probably not a massive piece of work. Unfortunately I haven't found any good documentation on how VS deals with Source Maps etc and so my suggested approach above is speculative at best. But maybe it's a starting point. Is anyone aware of any decent documentation on how VS deals with Source Maps? This may prevent wasted time....

SeriousM commented 11 years ago

Hi, is there an update available?

@dotnetchris i think the decision about when the source maps are available should be left to the user. In my scenario we have a staging system running which is debug=false and we need to find the problems on that system too which is very hard with minified files.

redbaran commented 9 years ago

I'm interested in this as well and I'd be happy if the debug-no-combine case worked. That seems to be the majority opinion. The AjaxMin issue is closed. This has been a great project and over the course of a year or so, this is the only issue we've run into.

mrchief commented 9 years ago

+1 for debug only support. Combine/minification etc. (if there is popular demand) can be rolled out in a later version.

Most Production deployments do not serve source maps anyway (security, obscurity, best practices to name a few reasons), so IMO, debug only support will be just fine.