sbt-js: add a //requirePlain "someFile.js" to concat a file without any treatment

[heralight]

Google closure is not supported by every library like modernizr. // require is a good directive then we can have a "// requirePlain" like to only concat the file, to avoid any modification.

[davegurnell]

I'm not sure what you mean. Does Closure Compiler break the code for Modernizr? If so, can you get around it with different optimization levels and/or externs?

I'm definitely interested in this kind of different treatment of different source files. I'm trying to work out how to piggyback commonjs / requirejs module syntax on top of what we have at the moment.

[heralight]

Actually, in my project, I use Lift as backend and a lot angularjs with modernizr and so and so... To concat and compress css and js I use your sbt-plugins and some sbt task like in https://github.com/heralight/lift_basic_runmode/blob/master/project/Build.scala I have try requirejs and commonjs, grunt but benefit is very poor against this simple solution and doesn't fit well with war architecture and non monolithic js application. But, there is a but, google closure break modernizr and some other lib with simple optimization level and under this optimization why use closure? That 's why my request.

My idea is to modify Graph class somehow to add a flag like "transformContent" Boolean, to continue support directive like "require" but skip google closure process.

Your idea to incorporate commonjs / requirejs module syntax could be a good idea, but with a lot of simplification like only declare a module, its dependencies, and how generate each dependency.

My alternative is to remove sbt-js and change for uglifyjs2 and a basic batch or sbt task...

anyway, your plugin is a nice work!

[davegurnell]

Ok - I understand the problems you're having. I've been using uglifyjs outside of the scala world recently and I find it a lot faster and more reliable for this kind of thing than closure compiler.

Moving on to the plugin structure as a whole, there are basically three steps:

1. Transform individual source files (coffeescript, commonjs, and so on):

File => File

1. Concatenate files together in some order to create an intermediate assembly file (this is where //require comes in):

Seq[File] => File

1. Transform the assembly file into a target file (google closure / uglifyjs):

File => File

Given the right architecture, it should be possible to implement these steps in any way we like. I'm thinking about pushing more of the functionality out to command line tools such as those provided by node.js. My main concern with this until recently was performance, but I now believe that with incremental compilation, things should be a lot faster.

Dave

On 13 Mar 2013, at 21:18, Alexandre Richonnier notifications@github.com wrote:

Actually, in my project, I use Lift as backend and a lot angularjs with modernizr and so and so... To concat and compress css and js I use your sbt-plugins and some sbt task like in https://github.com/heralight/lift_basic_runmode/blob/master/project/Build.scala I have try requirejs and commonjs, grunt but benefit is very poor against this simple solution and doesn't fit well with war architecture and non monolithic js application. But, there is a but, google closure break modernizr and some other lib with simple optimization level and under this optimization why use closure? That 's why my request.

My idea is to modify Graph class somehow to add a flag like "transformContent" Boolean, to continue support directive like "require" but skip google closure process.

My alternative is to remove sbt-js and change for uglifyjs2 and a basic batch or sbt task...

anyway, your plugin is a nice work!

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

[heralight]

right approach, have you planned something ?

[davegurnell]

Here's a very rough synopsis in pseudocode. It's incomplete but it gets most of the picture. Comments and feedback welcome:

https://gist.github.com/davegurnell/5162070

Dave

On 14 Mar 2013, at 11:48, Alexandre Richonnier notifications@github.com wrote:

right approach, have you planned something ?

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

[davegurnell]

The functionality discussed in this issue is available in the sbt-assets plugin on the feature/sbt-assets branch. I'm using it in production on one project but I don't currently have a release plan for it. Closing this ticket for now.