How to handle dist artefacts in commits logs

[ThaNarie]

We currently generate different output versions of the code in the dist folder, and commit them with every source change, so people that don't consume our module via NPM can grab the dist bundles from github (browser, amd, umd, commonjs, systemjs and es6).

Doing this, gives an enormous overhead in all the commits, where every change in the source results in 6 additional (large) bundle files being changed as well. This makes reviewing commits and PRs more overwhelming.

Ideally, we only want them in releases (tags), so I was wondering if we could find a better way to manage this?

Or should we skip generating them altogether (by default), and 1) only run them (manually) when upping the package.json version and creating a tag/release, or 2) let the consumer clone/build them and add them to the .gitignore?

We've chosen for option 2, and will add two additional methods of downloading them, via a hosted link and as a binary from the GitHub release.

• add /dist/ to .gitignore (Ignore /dist folder in git and update readme #17)
• only run dist script in travis, as an after_script (Change build-dist output and support S3 and Github Release deploys #22)
• add a travis s3 deploy configuration to upload the dist files to S3 (Change build-dist output and support S3 and Github Release deploys #22)
• add a travis github release deploy configuration to attach a zip of the dist folder to the release (Change build-dist output and support S3 and Github Release deploys #22)
• get access to production S3 bucket
• find a way to link to the latest version in the README.md or add a latest version on S3
• update README.md to explain this new workflow (Ignore /dist folder in git and update readme #17, Change build-dist output and support S3 and Github Release deploys #22)

[flut1]

Is it possible to .gitignore the dist files, let travis generate them and output them to some http server? Then we can link to those dist versions from our README.

[flut1]

e.g. http://seng.mediamonks.com/seng-xxx/latest/seng-xxx-moduletype[.min].js

[ThaNarie]

Alright, let's go that route!

• ignoring the /dist in .gitignore
• linking to hosted files we create in a travis build
• OR/AND adding the dist files as a single ZIP to a github release from travis using the API

Regarding the hosted files, we could upload them to an S3 bucket from within travis linked to a domain:

• use .org tld for open-source/community
• add /libs/ in between so we don't pollute the root
• use explicit version in url, latest could be trickier to provide; do we redirect them to the latest version (cannot be done with S3), or do we upload/override that version (invalidate caching, and how do we know if something is the latest, what if we patch a previous minor version, that's not the actual latest)

For amd/umd/browser/cjs
https://seng.mediamonks.org/libs/seng-xxx/[v1.0.0|latest]/seng-xxx-[moduleType][.min].js
Systemjs doesn't have a a .min version, because it's built with TS, could add uglify there?
es6 has multiple files, so we might want to create a .zip for that?

Steps are:

• add /dist/ to .gitignore
• get access to S3 bucket
• only run dist script in travis, as an after_script
• add an s3 node script that uses the aws-sdk to upload the dist files
• add a github node script that uses the github API to attach a zip of the dist folder to the release
• add section in .travis.yml to provide the secure S3 token
• update README.md to explain this new workflow

[ThaNarie]

In the readme I wanted to add links to the latest linkable version, but that's not really possible:

• we don't have a way to link to a latest version, and/or
• we cannot automatically update to the package.json version number in the README.md

1. Add a latest version
   This can be an extra deploy to S3 which replaces the files in the latest folder, and has a fairly short max-age header set. However, if we deploy a 2.0.0 version, but after that patch a 1.8.4 version, that last one will be set as latest. So we need to figure out a way to know if the new version is the highest version we have, and somehow figure out how to use that as a travis deploy condition.

Or we need a rewrite rule that dynamically points latest to the latest version on the server, but S3 is static and we can't support that.

2. update readme with package.json version
   We could create a script that parses the README.md for patterns where the version number is used, and update those occurrences with the desired version. We could run that script after we've updated the package.json version, or use that script to update the version in both the package.json and the README.md.

We could use a npm package that can bump major/minor/patch via the CLI, or even define a standard where each commit message should define if it's major/minor/patch, which can be used to update the version.

Any ideas @flut1 @art0rz @mientjan ?