Hi All! The CPE team is happy to announce we have released a new major version of the Node Orb!
This update includes a breaking change, so if your projects use the node orb, make sure you read the breaking changes section of this post.
Support for Yarn v2 Zero Installs:
Since Node Orb v4.4.0, support for Yarn v2 aka Yarn “Berry” has been provided. However, an attractive use case of this Yarn version called “Zero Installs” would require manual configuration. This was escalated to us through this GitHub issue. I want to give an extra thanks to Kurt-von-Laven for the very informative feature request!
To utilize yarn-berry, one would provide the yarn-berry
enum through the pkg-manager
parameter:
- node/install-packages:
pkg-manager: yarn-berry
Since these parameters are not passed:
check-cache
defaults to never
with-cache
defaults to true
We have provided a new parameter called check-cache
which is a Yarn Berry exclusive feature to solve for the security implications provided by Zero Installs as seen here. This feature allows the user to control whether the --check-cache
flag is passed to yarn install
command. When used in conjunction with with-cache: false
, (since there is no need for caching packages when using Zero Installs) the installation command is now prepared for version control stored packages.
- node/install-packages:
pkg-manager: yarn-berry
check-cache: always
with-cache: false
When check-cache
is set to always
, the --check-cache
flag is always passed to yarn install
. This is recommended for projects where the upmost security is required.
- node/install-packages:
pkg-manager: yarn-berry
check-cache: detect
with-cache: false
When check-cache
is set to detect
, the --check-cache
flag is only passed to yarn install
when changes to the yarn.lock
file are detected. This also enables an extra step which will handle caching the yarn.lock
file for you. This is recommended for projects where the verification of files packages is necessary, but users are generally trusted.
Not passing the check-cache
parameter, or providing the default never
value to it is only recommended for projects where contributors are completely trusted.
Changes to Node installation prioritization:
Previously, the latest
version of Node would be installed when no specified version was provided. This has been changed in favor for the lts
version.
The new order is:
- Install the latest version if
node-version
islatest
- Install the version specified if
node-version
is notlatest
- Use .nvmrc if it is present and
node-version
is not populated - Default to installing long term support if none of the above
Breaking changes:
There have been quite a few changes to the node_install
command’s parameters. Most significantly; latest
has been swapped out as lts
for the default node version installed. If you were relying on this functionality before, you must now pass node-version: latest
explicitly.
Furthermore, the lts
parameter has been removed as a result of it merging with the node-version
functionality. If this is being used, please remove it and ensure node-version
is not populated to install the lts version.
The parameters install-npm
and npm-version
have been removed. Since the appropriate npm version is installed with the installation of node, along with some issues where the version was not being persisted leading to build errors, we were motivated to remove this functionality. If your project requires a custom npm version to be installed, a run step using the npm install -g npm@<version>
can be added.
That’s all for v5.0.0! Thanks for reading, and happy building!