Vizabi-tool-bundler NPM

vizabi-tool-bundler

Shared build and CI scripts for vizabi tools

Contains

Shared rollup build script
Shared Travis YML config
Shared version bump script

How it works

When you run npm run build in your tool's repo folder it starts the automatic build with rollup. The rollup config is taken from this tool bundler. The shared rollup script also copies travis.yml into the repo which will later be used in CI. That way travis config is shared too from a single source.

You would normally use these scripts by running tools on preview page when developing, or in Travis CI.

🔢 Version bump

If version in package.json is the same or lower as latest published version on npm, then increase version to a next pre-release. 🌶 Note that prerelease version order is weird: 0.0.1, 0.0.2-1, 0.0.2-2, 0.0.2, 0.0.3-1 ...

👾 S3 deploy

Copies output files from /build to 2 locations: static.gapminderdev.org/<your_tool_name> (latest build) and in static.gapminderdev.org/<your_tool_name>/. Versioned builds would be used in other tools and projects.

📦 npm deploy

Publishes the built version (possibly bumped with a pre-release suffix) to npm

🙈 Gapminder tools page deploy

Logs into tools-dev instance on Digital Ocean over ssh and runs this script. Tools page DEV (and only dev) fetches the latest published tools from npm, thus the fresh build would also feature your latest updates.

How to set up

Best to follow example of how it's done in one of the existing tools. For example, line chart

Create your vizabi tool, add dev dependencies "vizabi-tool-bundler": "github:vizabi/vizabi-tool-bundler" and "cross-env": "^5.0.0" in package.json
Add files rollup.config.js and rollup.external.js (don't forget to specify the name of the tool in the latter, like so)
Add scripts: "start": "rollup -c" and "build": "cross-env NODE_ENV=production rollup -c" in package.json
Now you should be able to run npm install and npm run build in your tool folder locally
Set up github webhook to trigger Travis build on push event
Enable the tool repo in Travis CI interface
Configure travis environment variables in repo settings:

AWS_ACCESS_KEY_ID = check in AWS admin web interface, under cridentials of Travis user, looks something like AKIA************YEWP
AWS_BUCKET = static.gapminderdev.org
AWS_SUBFOLDER = your tool name such as vizabi-linechart
encrypted_6f3bd6d63370_iv = these two are the private and public keys for accessing tools page over SSH
encrypted_6f3bd6d63370_key = you can read more in this article
TOOLSPAGE_HOST = IP or DNS name of tools page server
TOOLSPAGE_USER = username to log in over ssh

Note that S3 secret ID and NPM auth key are not listed above, instead they are encrypted and pasted directly in .travis.yml
Disable build config validation in the bottom of the page (repo settings on travis)
Push your tool to github repo and watch the build on travis.

How to use

1. Use case: make changes in a tool, publish to S3, NPM, tools-dev:

Change the tool code, check your changes in preview page
Build the tool locally using npm run build, take care of any errors and warnings
Push your changes to master branch of the tool, the build should propagate as needed

2. Use case: try out some changes in a tool but don't push to S3, NPM or Tools-dev:

Same as 1 but push your changes to a feature branch instead of master

3. Use case: release a new version of the tool

When you are happy with the changes you want to release
Check the latest published version on NPM using npm view <your_tool_name> version
Update manually version number in package.json: if it's a major (X.x.x) or minor (x.X.x) version, set the new version code as you like, the version should be ahead of the lates published one. If it's a patch (x.x.X), look if there was a pre-release in the latest published. If there was, use that release (example: x.x.2-1 is latest published, use x.x.2), otherwise use next release (example: x.x.2 is the latest published, use x.x.3)
Commit, build, push changes to master