Support for source map generation

[bbergstrom]

I know there is an old ticket in your Google project, but wanted to get it into your more active Github space for discussion. https://code.google.com/p/wro4j/issues/detail?id=517

I have been tossing around ideas in my head of how to add support for generating source maps to wro4j, but am encountering some big issues. Thought I would start a discussion about this to see if there is a viable way to implement this.

References

• https://github.com/ryanseddon/source-map/wiki/Source-maps%3A-languages%2C-tools-and-other-info
• http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/
• https://github.com/mozilla/source-map

Dependencies

The first question is what information does the source map generation depend on? It needs to know the generated filename, which would be the group name possibly with a naming strategy. It needs to know about the original source files in each group, which are all in the model. It needs to know about the resulting group code files after all concatenation and processing is done. It also should be minimize aware, because the resulting code will differ based on minification. Or at the least, work only in non minified mode, because this feature is really for development, not production.

Design Ideas

Closure

The google closure compiler that is part of wro-extensions already supports source maps, lets take advantage of that.... but this is a processor that will only know of the source files(pre) or the concatenated source(post) and may not be the last processor in the chain. This processor could be extended to be run as both pre and post, persisting information between the two process calls for the mappings and require it to be the last JS processor in the chain. This doesn't do anything for CSS source maps from LESS/SASS.

LESS

LESS.js has support for generating source maps. But, it needs to know the source files. wro4j Less processors are required to run as post processors in order for mixins/variables to resolve across LESS files. Same issue as Closure, the post processors need to know about the source files.

New Processor

We could make a AbstractSourceMapProcessor, with a sub class for JS and CSS. This would need to run as pre and post, persisting information in the thread local context(or some other means) across the process calls to generate the mapping afte the post processing.
This would likely have to take advantage of the 'sections' part of the spec, so that the maps for each source file could be put together after the wro4j group concatenation. See Source Map Rev 3 doc section titled 'Index map: supporting post processing'. This is where I hit another problem. LessProcessor is required to run as a POST This could run similar to the RhinoLessProcessor, using the Mozilla Javascript based source-map library.

Problem Context

For some context on the problem I am solving. Our initial plan was to use 'exploded' mode from the taglib for development, which allows developers to see where the source is for generated CSS. https://github.com/ibsys/wro4j-taglib#style-syntax But, this doesn't work because we have multiple levels of LESS stylesheets which have variable/mixin dependencies(Bootstrap, product, client, site). This works out great when compiling server side using wro4j, but we need a less painful way to develop LESS.

• Considered removing the LESS dependencies, but that causes us to lose a lot of the benefit of using Twitter Bootstrap.
• Thought about modifying our WRO model, so that LESS is chained via CSS imports, which would work but makes LESS the exception in our WRO model and would cause us to always create duplicate WRO groups(one with LESS, one without).
• Could extend the wro4j-taglib so when it detects LESS in exploded mode, to create a fake LESS wrapper stylesheet that imports all the less. The main problem with this is that the generated fake LESS wrapper will have to be at the end of all the tags on the page, which could affect behavior.

I look forward to your input on the topic.

[alexo]

@bbergstrom thanks for such detailed description of the problem. I will think about it and will get back to you.

[dominiclovell]

+1 for this ticket. Any plan for this @alexo?

[alexo]

Currently I'm focused on finishing issues for release 1.6.4. There are still issues and deffects which worth fixing before adding new features.

However, if there are anybody really interested in making this feature a priority, a contribution would help a lot.

Cheers, Alex

[mlb6]

Hi @alexo, I would be really interested about this new functionality. Is it still in your backlog ? Is it already planned for a future release ?

Thanks for this great project ! Martin.

[alexo]

@mlb6 it is on the backlog, but I can't really promise working on it anytime soon. However, I would gladly merge pull requests for this (or any other) issue from the backlog.

[wmitchellUK]

+1

[marbetschar]

+1 any news so far? Unfortunately I'm not that fit in Java to put the changes in by myself :( Maybe the easiest implementation is going for an option to enable source maps when the Closure Compiler is used?

[mindhaq]

+1

[3urdoch]

+1

[Tunell]

+1

[codeturner]

+1

[alexo]

The project was migrated to a new location. The related issue is https://github.com/wro4j/wro4j/issues/517