In the last decade, Javascript (JS) has been increasingly used for backend software development, especially since the first appearance of Node.js.  Listed below are some of the most common processes that are involved in a Javascript project lifecycle in several JS ecosystems/platforms, and how they interact with the project infrastructure provided by the Foundation.

Node.js

Node.js is a Javascript runtime for running JS code; the node command line is easy to install and provides a rich set of options to manage the entire project lifecycle.

Publishing on npm

npm is the Node.js package manager, enabling developers to fetch and publish Node.js packages; project teams can use their own npm credentials to publish packages (locally or via CI), or ask help@finos.org to support setting up the release process.

To date, the Foundation has provisioned:

1. A FINOS NPMJS Organisation, that is used as a directory of all NPM packages that are released from a FINOS hosted project or working group.
2. A FINOS Admin user, which can be used to publish NPM packages to NPMJS, if a Project Lead is unable to create a personal account to do so
3. A Symphony Software Foundation NPMJS Organisation, that houses all published Node.js packages from the Symphony Program.

Using package scoping

All npm packages released under the Symphony Program's npm organisation should define the @finos scope, in order to point to the npm organisation; if you're not familiar, read more about scoped packages.

There are some situations where it is not possible to specify the scope of a package, since scoping maybe used for behaviour-related aspects of the application; for example when defining typescript typings.

Semantic release

Semantic release is a Node.js library that automates the software release process by parsing commit messages; on every commit, semantic release is executed by Travis CI and - based on the commit message - decides to trigger a release or not; release managers can use commitizen (see image below) to simplify their commit process; simply install npm install -g commitizen and use git cz (instead of git commit) to commit your changes.

It is worth noting that release managers have the opportunity squash and merge using GitHub merge UI, in order to choose the right commit messages and keep commit log clean.

When a release is performed, Travis CI will do the following:

• Run all build and validation tasks defined by .travis.yml
• Create a GitHub tag, labelled after the version specified in package.json
  • Include a CHANGELOG.md file with a recap of all commits added since last release
  • Publish (on npmjs.org/org/finos) an updated version of the NPM package defined by package.json
• Increase the the version specified in package.json and push changes to master branch

Release setup

Travis CI must be configured with the following environment variables:

• GH_TOKEN, used to create tags on GitHub
• NPM_TOKEN, used to publish the npm package

You can setup variables using semantic-release-cli, Travis Repository Settings or with the travis CLI.

Release configurations can also be shared across npm projects.

Advanced configurations

Semantic release allows additional configurations to customise the release flow.