Consider a "removeCombined" option for build about r.js HOT 10 CLOSED

This addon will be much appreciated

from r.js.

In the meantime, you can use this approach to do multiple "single file" builds by creating a script in node to drive the build multiple times: https://gist.github.com/1509135

from r.js.

This would be a much welcome addition!
Just as a thought on the current structure of the build config, i had actually tried to achieve the same result using the following (without reading the manual of course!):

modules: [
{
name: 'foo',
include: ['bar']
out: './deploy/baz.js'
}
]

... following the same structure of a "single file" build, but defined within a module element. Just throwing the "out" option as an idea as well as removeCombined.

from r.js.

@bustardcelly that is possible today, just take the name, include and out options and place them at the top level of the build config, not inside modules, then remove the modules area. I will be pushing out a doc update this afternoon that makes this clearer.

from r.js.

Yeah I've set something simular up now. To make sure not only the module + dependency files are copied, but also my css etc I'm using an ant build file, could also be done in node.js of course.

from r.js.

@jrburke right. sorry i meant to say that i actually have a list of modules and have tried adding the out option to each.
eg.

modules: [
{
name: 'foo',
include: ['bar']
out: './deploy/baz.js'
},
{
name: 'qux',
include: ['quux'],
out: './deploy/corge.js'
}
]

The single module approach, each declared in its own build config, is what i currently do and have a script to cycle through and invoke r.js for each one - much like the gist posted previously.

from r.js.

+1 It'd very desirable feature. As now with config-based build we have to add some custom build step for cleaning source files.

from r.js.

+1

from r.js.

+1

from r.js.

This is in the dev2.0 branch, and will be in the 2.0 release. If you are comfortable using dev2.0 code you can try it out (make sure you get the latest require.js from its dev2.0 branch too). I would encourage more testing. While I have a couple of unit tests in for it now, the more testing the better.

from r.js.