Distribution plan

[timrwood]

In order to minimize chaos, it would be nice to have separate repos for source files and distribution files.

Unfortunately, because so many package managers use git urls as their sources, I don't think we can host distribution files on another repo like component/moment.

I think the best plan would be to create something like a moment/moment-source repo that all development is done on, and the only commits on the moment/moment repo would be compiled builds.

Anything specific to distribution would live in moment/moment, and anything related to development would be in moment/moment-source.

# moment/moment
min, .npmignore, .spmignore, changelog, contributing,
license, readme, bower.json, component.json,
composer.json, ender.js, package.js, package.json

# moment/moment-source
benchmarks, locales, lib, tasks, test, .travis.yml,
contributing.md, readme.md, gruntfile.js, brocfile.js, package.json

For the compiled builds, we will probably want to target es6, globals, amd, commonjs, and umd. The file tree might look something like this.

amd/
    locales/*
    moment.js
commonjs/
    locales/*
    moment.js
es6/
    locales/*
    moment.js
globals/
    locales/*
    moment.js
umd/
    locales/*
    moment.js
component.json
composer.json
bower.json
package.json

For all these environments we will probably need to decide whether to bundle the source into a single file or not.

We will also need to figure out if we want to have a version with the locales bundled, a version without the locales bundled, or both.

We should also consider if we want to provide a minified copy of each version.

Environment	Bundled?	Minified?	With Locales?	Without Locales?
amd	Y	Y	Y	Y
commonjs	N	N	Y	N
es6	N	N	N	Y
globals	Y	Y	Y	Y
umd	Y	Y	Y	Y

[trek]

I have specific (and long) thoughts about this generally. I've been spitballing ideas with @fivetanley about ways to resolve this problem. I need to put some investigation time in this weekend before we get anyone's hopes up.

I think your general repo plan is a good idea as an easy migration; although I HATE that we're polluting github with non-source code and it comes with annoying logistics overhead (you won't believe the number of PRs you'll get targeting the publish repos instead of the source repos).

If we publish amd, cjs, es6, and globals, I don't think there is any value in adding a umd build.

[trek]

There's now a bower issue about some of these ideas: bower/bower#1606

[timrwood]

Another thing to look into is https://github.com/6to5/6to5

[trek]

I usually prefer https://github.com/esnext/es6-module-transpiler for a few reasons:

• existing broccoli support
• limited to ES6 modules
• opt-in to other ES6 features if you want them
• @eventualbuddha is super nice

[ichernev]

If we have a chooser on the website for all the packaging, minification and bundling options that would be epic. So you choose with some checkboxes, and then there is a grunt command to run on the distribution repo, or a zip to download (for all the ones who don't have node and don't want to bother).

About distribution: I've seen projects do separate repos for particular build systems (like https://github.com/angular/bower-angular). If the system is push based (like npm, spm, nuget, meteor), then you can have a grunt/bash script that makes a directory with the right structure and publishes that. No even need to put the package.json file (for example) in the root directory. If it's autodetect, then we should have a separate repo per environment (or share a repo in between a few environments).

Another thing to take into account is how easy it is for a person who have read the bundled version to figure out where stuff is in the source version and how to build one himself -- because that is what most devs would need anyway (when they hit a crazy bug we won't fix). So having many repos and scripts that do stuff gets in the way. Also I don't see why not use a single repo with a build folder that contains all the products. Most autodetect systems only get activated on tags, so its fine that most commits won't touch the build. I'm personally for that approach:
-- one repo
-- build folder
-- separate environments go in subfolders
-- if its publish based we just publish the subfolder
-- if its autodetect (we can't do anything here), we can make exception for bower (separate repo, like angular), as the most widely used

[marshallswain]

You might consider using StealJS's steal-tools for builds: http://stealjs.com/docs/steal-tools.html. You can set it to use either Babel or Traceur for transpiling.

There's a quick start tutorial to get an idea of how it works workflow-wise: http://stealjs.com/docs/StealJS.quick-start.html

If you'd like to see an example of how the builds work you can look at this project I've just started: https://github.com/marshallswain/can-stache-moment.