JavaScript FAQ

Which versions of Node.js does Release support?

You can use any version of Node.js with Release.

For Docker containers:

For Docker containers, you can pull in a source image and version with a tag like FROM node:16 at the top of your Dockerfile. Internally, we use nvm and recommend you do too. Take a look at this example of adding nvm to an Alpine image.

For static build images:

For static build images, we use nvm, which will use whatever version of Node.js you have in a .nvmrc file. You can specify a global version at the top of your build directory and override it with different versions further down the directory structure if you need to. Read the nvm docs for more information, or take a look at this Stack Overflow answer.

How to Control JavaScript Out of Memory or Performance Issues?

JavaScript default memory heap settings are usually correct. Setting your pod memory resource limits between 1 GiB and 4 GiB should be fine. But restricting the amount of memory available to JavaScript may result in bottlenecks and slowdowns that are not easy to predict or understand. Generally, JavaScript will only use a single CPU and therefore, allowing the CPU to address more memory can allow the CPU to be free to process more data without waiting for objects to be swapped in and out of working memory. However, just as JavaScript cannot generally use more than a single CPU, it cannot address more memory without further help. Typically, you will need to set an environment variable or build argument to address memory above the 4 GiB-32 GiB range.

As an example, given the following memory limits:

resources:
  memory:
    limits: 9Gi
    requests: 4Gi

The appropriate environment variable settings would look like this:

services:
  frontend:
  - key: NODE_OPTIONS
    value: "--max-old-space-size=8192"

In this example, we set the options to pass to the Node application to use 8 GiB of RAM. Notice this is slightly less than the limits set by the pod resources since the container will use more memory than just the old space size.

To ensure that your application has enough CPU resources, we do not recommend setting the resource limits higher than 1 since JavaScript is usually single-threaded. However, we do not recommend setting the requested resources too low either, since that can cause scheduler and contention issues in your Kubernetes cluster at the node level. We encourage you to use the following CPU resource limits for any production or performance-based JavaScript applications:

resources:
  cpu:
    limits: 1
    requests: 1

How to filter excessive log entries in Yarn?

Yarn will often output multiple hundreds (or even thousands) of log lines for debugging output. This can bog down the build process and slow down scanning the logs for useful information. Add the following to your .yarnrc.yaml file to filter out certain types of Yarn log output lines:

logFilters:
  - code: YN0013
    level: discard

Here, we specify to exclude the debug output YN0013, which shows the package being fetched and installed, usually many in any node_modules directory.

You can add more filters to exclude log output lines that are not important to you.

Does Release support private npm libraries during build?

Yes, but using npm libraries might require some additional work on your part. This guide to Docker and private modules from the npm documentation provides all the technical details. In brief:

1. Add a .nprmrc file to your code repository with contents that look something like //registry.npmjs.org/:_authToken=${NPM_TOKEN}. Do not fill in your token here, but rather use the variable that will be substituted later (this file is safe to check into your code version system).

2. Add a build argument to your Dockerfile, preferably somewhere near the top (add a comment so you can remember why you put it there). The line looks like ARG NPM_TOKEN.

3. Add a copy command so the file is copied into your Docker container. The copy command should be placed below the build argument but above the npm install command. The line looks like COPY .npmrc .npmrc.

4. Push your changes to GitHub or Bitbucket on a branch.

5. Be sure to generate a token or use an existing token that is READ-ONLY and can be revoked safely without affecting your other pipelines. Anyone who is an owner of your Release account can see and change these build arguments.

6. Add your token to a build argument in the Build Arguments tab of your Configuration settings:

Once you've completed these steps, your build should use the npm token you supplied to pull private libraries. If it works, merge your changes to the default or main development branch.

Can I use GitHub Packages with Release?

To install GitHub Packages, you'll need to follow the same steps as outlined for npm repositories above. Ensure that your token has privileges for ['read:packages']

Your .npmrc file should look similar to:

//npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}
@myorg:registry=https://npm.pkg.github.com/

What about static service deployments?

For static service deployments, you can use environment variables to add your token. Remember to add secret: true.

While app-level build arguments will work for static service deployments, these are usually reserved for Docker images.

Does Release support Yarn?

To use Yarn, follow the instructions for npm above, then add a .yarnrc.yaml file for the private repository. Take a look at this Gist for more information.