Skip to main content


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 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 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.

Using package scoping#

All npm packages released under the FINOS 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 type 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, your CI environment will do the following:

  • Run all build and validation tasks defined by your build descriptor (ie .travis.yml)
  • Create a GitHub tag, labelled after the version specified in package.json
    • Include a file with a recap of all commits added since last release
    • Publish (on 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 or the CI environment of your choice (see how variables are set in GitHub Actions)

Release configurations can also be shared across npm projects.

Advanced configurations#

Semantic release allows additional configurations to customise the release flow.