Future Directions

This doc is somewhat outdated - some of these topics have been addressed as of 0.7.x*

Dynamic Code Serving

If I can build a hotel (static), why can't I serve tourists (dynamic) ?

Building is such an outdated & static concept.

Certainly for most browser apps, having a combined file (with a one-size-fits-all), might be better than having to load all individual AMD dependencies from the client, where a separate http call is needed for each module. Download size matters less than latency, especially for high bandwidth clients (but not so much for Mobile clients).

But with dynamic environments & languages like javascript, you should be able to serve your running app with only the exact code it will require and nothing more. All non-always-needed code can be retrieved dynamically via asynchronous style requires.

Out of your whole code base, you application server should be able to dynamically determine what dependencies 'MyLib.js' requires, bundle them all up and send it to the client. Caching would make this really scalable; only when the code base changes there would be a need for one build of each requested dependency.

In same way, you can still do this with current version: just set template:'combined' and main:'someModule' and only 'someModule' and its dependencies will be bundled by requirejs.

uRequire is currently a build system by accident, but since its aware of modules & dependencies, it could evolve into something like a dynamic code serving system.

Dynamic Resource Loaders

Are all resources equal? Required dependencies are resources that are more equal than others.

Imagine having require('mytextfile.txt') or require('mytextfile.json') as a valid way to load resources, much like RequireJS Loader Plugins, but having a default plugin (& settings) for each extension (eg 'json': 'requirejs-plugins/json')

Now imagine declaring the 'require'ment of all you app's resources, either an .md, an .xml, a template like coffeekup or jade etc. And voila you have your resource available & converted, either at build or even at run time.

Many considerations are needed here, but it'll be an excellent way to unify how static resources are referenced as dependencies with one unified way.

In Memory Resource Conversion Pipelines

Who needs plugins ? All resources just need some conversion, dont they?

Although at its infancy, bundle.resources aims to power a streamlined light-weight conversion process. With its in memory conversion pipeline and its simplistic declaration, you can easily define :

• new types of modules source languages (eg. Livecript, coco etc). For example check how trivial the coco module converter from MasterDefaultsConfig is (coffee):

     [ '$coco', [ '**/*.co'], (-> (require 'coco').compile @source, bare:true), '.js']

Not much of a plugin eh? It works in the most minimal way; the only thing required is npm install LiveScript

• concat type tasks are also trivial - check this concat task (coffee) from uBerscore:

    [ 'injectVERSION',['uberscore.js'], ->"var VERSION = '#{pkg.version}';\n#{@source}"]

In summary, with bundle.resources as they are in 0.5.x, you can devise any short of 'plugin':

• Code compilation of modules written in any languge that produces pure commonjs/AMD javascript (typescript, coco etc).

• Code transformations (eg remove debug code - i.e starting with if (debug) ...)

• Concatenations, code injections, banners, adding build time bumbed version numbers, etc.

• Convert non-javascript code from one format to the other (eg .less -> .css) etc

• any other conversion/check you can think of, like linting etc .

More functionality is needed towards this aim :

• In memory pipelines need more thought and should be more sound; having some information about where to go next would be good.

• handling of non-textual resources (gifs etc)

• Currently when the same dstFilename is encountered in two or more resources/modules, an error is raised. But this could perhaps mean pre- or post- conversion concatenation:

  • either all source texts are concatenated & then passed to convert, which ends up to dstFilename.

  • or each resource is converted alone & their converted texts are concatenated onto dstFilename.

Various todos / additions

Using @todo: UEG scheme - check todo-notes.md

uRequire.config

• (4 5 6) blend requirejs config & smootly integrate it! uRequire can use but also generate the requirejs config needed at run time.

• (4 4 8) Check / cowork / integrate / piggyback with others :

      bower, brunch.io, yeoman.io, jam, package.json, requirejs.packages etc

build

• (6 4 5) Allow global deps to be included in a combined build.

• (4 7 6) Use sourcemaps for build code

• (5 5 4) Sanity checks of existence of external libraries, webRootMap, baseUrl, paths etc.

Module manipulation

• (2 2 8) Read/write Harmony modules

• (2 2 6) Read/write Coffescript modules - use coffeescript redux - rewrite Templates for Coffeescript