Build workflow

[guybedford]

I've managed to get a full production build workflow going.

You can see this in my fork here - https://github.com/guybedford/traceur-todomvc

The production app is at index-built.html

I haven't created a pull request, because it uses the SystemJS project, which is still not completely launched.

The build process is the following:

1. Compile js -> js-built turning ES6 in ES5 and AMD
2. Use the r.js optimizer to compile the AMD into a single file
3. Use the traceur runtime and systemJS AMD-production module (finished yesterday!) in the production environment.

Currently the above is just in a Makefile. This can be done through any other tool as necessary.

Feedback welcome.

[guybedford]

Just to clarify the build situation here. Basically we have the following options:

1. Use Traceur to compile the modules into a single file that can work in production. We don't get spec-compliant dynamic module loading in this scenario.
2. Use Traceur to compile into AMD, and the r.js optimizer to compile into a bundle to populate the ES6 module registry (as above). The benefit here is that the module registry is populated, so dynamic loads can work using the System loader, sharing the initial page load registry.
3. We're currently collaborating on Traceur with an ES6-specific bundling output. This output from Traceur could work directly with the ES6 Module Loader to populate the registry, without needing to go via AMD.

Perhaps it's worth waiting on (3), which with some luck will have some progress this week.

It may well be suitable to use (1) entirely for this project, bypassing the ES6 Module Loader entirely. My preference is the System loader because dynamic loading is needed in any large web app, so rather get going with a workflow that will scale, than starting with a static workflow, and then having to change.

But all that said, we can set that up if you like.

Hope that clarifies some of the module loading options - I'm finally getting down to some blog posts on the above to make this information more widely available.

[addyosmani]

Thanks for researching the various options available to us here, Guy. I think a build story to accompany the example would be terrifically useful. My two cents:

I would love for us to be able to offer (via the build process) a way to output a few different variations of the application - if that is, we don't think it would take up too much of your time.

Side: Grunt is currently the most commonly used tool for build task running on the front-end. Perhaps we could use it to lower the barrier of entry to developers interested in this problem space?

• grunt build:production - generates (1)
• grunt build:bundle - generates (2) or (3)
• grunt build:raw - optional, but basically a way to output the current version of the project with the hard dependency on Traceur and the ModuleLoader/System being included. This is really just here in case we have trouble with the 'out-of-the-box' experience being runnable.

[guybedford]

I'll most likely need to get a PR into https://github.com/aaronfrost/grunt-traceur to get this updated.

I'm actually giving a talk on this workflow early next month, so this would be ideal for me as well. Will get to this soon, as I hope the PR will can get through in time.

[guybedford]

I'm keen to see this grunt workflow, unfortunately I won't have time to work on grunt-traceur until later this month now, which is a little annoying as ideally that is the workflow we want to share with users.

If anyone is keen to work on this, I can directly translate how the commands would match up to the Traceur arguments, it's just the process of putting it all together and updating Traceur that I can't assist with right now.