Skip to main content

npm and nvm

Setting up npm registries​

In your user home directory (~/), you need a .npmrc file. In this file, we can add package registries. To add all existing registries (to which you have access with your GitLab user account), you need at least a simple .npmrc file.

@cloudsuite:registry=https://gitlab.com/api/v4/packages/npm/
//gitlab.com/api/v4/packages/npm/:_authToken=your_gitlab_access_token

Replace your_gitlab_access_token with the actual access token obtained from GitLab. This can be generated here.

This approach eliminates the need for setting environment variables for each token, making the configuration more contained within the .npmrc file. Instead of including separate .npmrc files in each project, a centralized .npmrc file in your home directory provides a streamlined approach for local use. Managing configuration in one place allows you to keep package registries, authentication tokens, and other settings consistent. This saves time and prevents confusion when switching between projects.

You should, therefore, never see a .npmrc file in a project. These are typically handled through the pipeline to ensure the correct registries are set. If you see an .npmrc lingering in a project, remove it!

Using $ Tokens for Environment Variables​

@cloudsuite:registry=https://gitlab.com/api/v4/packages/npm/
//gitlab.com/api/v4/packages/npm/:_authToken=${GLPRIV}

In the examples, you may have noticed the use of $ tokens for variables such as $GLPRIV. These tokens are placeholders for actual variable names and are commonly used in various documentation.

When configuring environment variables in your shell profile file (e.g., .bashrc or .zshrc), the convention is to use uppercase letters and underscores, but this is not mandatory: you can choose any variable name that makes sense to you. For example, you can export the GitLab access token like this:

export GLPRIV="Your obtained private key goes here"

This flexible approach allows you to customize variable names according to your preferences, making it easier to manage multiple tokens or follow existing naming conventions in your projects.

Remember to restart your terminal after making changes to ensure that the environment variables are loaded correctly.

Windows users​

On Windows machines, you need to define global environment variables, which are always available to all Windows processes and users. How this is done depends on the version of Windows you are using: Open the Start panel, then search for Environment (or Omgeving in Dutch) and take it fom there. Add a new environment variable with GLPRIV as the name and <your-access-token> as the value.

To ensure that the building of templates work on Windows machines, we make use of the cross-env NPM package.

  1. Install cross-env by using the command npm install --save-dev cross-env.
  2. To use the package, write cross-env-shell in front of the templates script in the package.json.

Node Version Manager (NVM)​

There is not a lot you need to get started when you meet all requirements and tools. We have many different themes, old and new. There are differences in usage of node versions.

nvm allows you to quickly install and use different versions of node via the command line. The installation guide can be found here.

Example
$ nvm use 16      # Now using node v16.9.1 (npm v7.21.1)
$ node -v         # v16.9.1
$ nvm use 14      # Now using node v14.18.0 (npm v6.14.15)
$ node -v         # v14.18.0
$ nvm install 12  # Now installing and using node v12.22.6 (npm v6.14.5)
$ node -v         # v12.22.6