Add a RequireJS model transformer

[GoogleCodeExporter]

RequireJs is a JavaScript file loader. 

Each files are defined like this : 

    require(['lib/myDependency'], function { 
      //Do What you want 
    });

When requireJs load that file, it will also load its dependencies, and the 
dependencies of the dependencies, ...

Without a requireJs PreProcessor, every js files are grouped as defined in the 
WroModel (wro.xml), and not as defined by the requireJs dependencies.

When several requireJs dependencies are grouped by Wro4j, multiple require 
statements are present in the same file. Actually, to make requireJs works, you 
have to use named module : http://requirejs.org/docs/api.html#modulename

A RequireJs PreProcessor will process every requireJs files and replace it by 
the grouped version (not compressed)

Original issue reported on code.google.com by filir...@gmail.com on 21 Jul 2011 at 7:17

[GoogleCodeExporter]

Original comment by romain.p...@gmail.com on 21 Jul 2011 at 7:18

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 24 Jul 2011 at 9:14

• Changed state: Accepted

[GoogleCodeExporter]

This feature should be actually implemented as a model transformer, rather than 
a resourcePreProcessor. A good example is: WildcardExpanderWroModelTransformer 
(in branch 1.4.x)

Original comment by alex.obj...@gmail.com on 24 Jul 2011 at 11:23

• Changed title: Add a RequireJS model trasnformer

[GoogleCodeExporter]

Original comment by alex.obj...@gmail.com on 25 Aug 2011 at 3:49

• Changed title: Add a RequireJS model transformer

[GoogleCodeExporter]

This is an interesting problem. I assumed the answer was to run the RequireJS 
optimizer r.js (see issue #367). This would mean a transformer that kicks off 
an external JS process. That process would then create a single js file 
combining all the existing js files in the group as well as their dependencies. 
The model would be updated to just that one file and it would carry on through 
the preprocessers etc.

[a.js, b.js] -> [abcd.js]

Alternatively we do our own implementation without r.js The transformer could 
read the js files in the group and find their dependencies. (and recursively 
find the dependencies of the dependencies etc.) Then without writing anything 
to disk it would transform the model to include all dependencies.

so 

[a.js, b.js]  --> [a.js, b.js, c.js, d.js]

Now each of the js files and their dependencies get run through the 
pre-processors separately. This seems more in tune with the wro4j design and 
maybe allow some different use cases like js scripts that depend on coffee 
scripts.

Thoughts?

Original comment by thejos...@gmail.com on 16 Mar 2012 at 11:07

[GoogleCodeExporter]

Yes, this is doable. The challenge of tjis task is to create the require.js 
parser, locate and build a graph of dependencies, in order to identify cycles 
and order them properly.

It would be great to start a draft implementation. Any volunteers?

Original comment by alex.obj...@gmail.com on 17 Mar 2012 at 9:24

[GoogleCodeExporter]

One more idea:

when using requireJs model transformer, no wro.xml (or other) model is 
required. 
The initial request can be for a single physical resource which is used as an 
entry point for building the model from dependencies it describes. 

Example:
1) Map wro4j filter to *.js
2) intercept the request for the /static/start.js
3) start.js is a resource which has the following dependencies [a,b,c,d]
4) Compute the graph of dependencies (and dependencies of dependencies)
5) Build the model based on computed dependencies and apply processors (merge 
them)
6) Cache the result based on requested uri (used as a group name)

The advantage of this approach is that you can easily switch wro4j with 
require.js with no extra configuration (just by removing the filter). 
Also there is no need to build the model in a specialized DSL, as it is build 
dynamically by parsing the js.

Original comment by alex.obj...@gmail.com on 17 Mar 2012 at 10:13

[GoogleCodeExporter]

Another idea is to let the user himself define his own configuration through 
AMD-layers. Basically borrowing much of the ideas from dojo's build system. I 
have written about dojo's build-system here: 
http://ivarconr.wordpress.com/2012/01/07/custom-build-in-dojo-1-7/

In development the layers would be "empty" (only define the layer itself) and 
thus require the user to fetch all modules individually. In production the 
layers will be filled up according to the layer definitions, with all the 
dependencies, and child dependencies included in to the layer. 

For the user he would need to account for the layers in his code:

require(["mycompany/layers/core"], function() {
  require(["mycompany/widgets/Example","dojo/domReady!"], function(Example) {
    new Example({}, "app");
  });
});

Example can or can not be included in the core layer. If it is included no 
subsequent request are required.

The question then comes down to:

1. How should the layers be defined.
2. How to build (traverse though js-files) the layer-bundles. 

Original comment by ivarc...@gmail.com on 2 May 2012 at 9:18

[GoogleCodeExporter]

Actually I think having the dependencies in xml files is not a good thing. The 
approach in require.js and less is better because your dependencies are in the 
code that depend on it. Not in some obscure xml config file.

Too bad this was never implemented. I recommend using a requirejs maven plugin.

Original comment by tje...@gmail.com on 4 Feb 2013 at 3:25

[GoogleCodeExporter]

The requirejs was designed to work only with javascript resources. 
wro4j can be used to manage both: js & css resources. 

Having a single configuration file, can be obscure for some use-cases, but does 
make sense for others. Besides that, a xml configuration file is just one of 
existing ways to configure a model. The design is pretty flexible and allows 
you to use other DSL's like groovy or JSON to describe dependencies. Also, it 
does not exclude a way to configure dependencies programmatically based on your 
custom needs. Theoretically, it is possible to implement a model which is built 
after parsing all javascripts from your project and build dependencies the way 
require.js does. The problem is that it is not easy to define the approach for 
such solution. This is something we've been discussing on the mailing list, but 
there was to little feedback. 

The wro4j is feature driven. It is unreasonable to implement features without 
having a good understanding of how these will be used.

I believe that the best tool is the one which does exactly what you need. So, 
as long as you are happy with require.js and require.js maven plugin, I don't 
see why would you look for an alternative implementation with similar features.

Cheers,
Alex

Original comment by alex.obj...@gmail.com on 4 Feb 2013 at 4:38