How to update npm used for Oryx?

[SvenAeltermanInfo]

On every single build, we receive the following warning:

npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it!

While the build succeeds, I would rather be able to update the npm version that Oryx uses to the latest.

To Reproduce
Steps to reproduce the behavior:

1. Create a Node.js project that uses an npm version >= 7
2. Attempt to deploy to a SWA

Expected behavior
I think I understand why keeping an older npm version on Oryx makes sense (for those projects with older npm versions and lockfile versions), but I would like to be able to upgrade the version used for my builds.

Additional context
I have tried adding a step to the job containing npm install -g npm@latest. That command executes successfully, but it doesn't affect the npm version used in Oryx, which is 6.14.15.

[anthonychu]

@william-msft is it possible to control the NPM version, perhaps using the engines field in package.json?

[mxwlf]

+1. As of now, create-react-app is creating the lockfile with "lockfileVersion": 2.
Any recently created project using this action will fail.

[william-msft]

Hi @anthonychu, specifying npm's version in the engines in package.json won't work because Oryx's npm version is locked to 6.14.15. We can look into upgrading npm version or perhaps allowing control via the engines field. Please let me know.

[anthonychu]

Yes we need some way to specify the npm version. Not really sure what’s the best thing to do here. @simonaco @Reshmi-Sriram

[william-msft]

Thanks Anthony, we have a work item for this cc: @daniv-msft

[cormacpayne]

@simonaco @anthonychu @Reshmi-Sriram -- wanted to double check how feasible the below solution may be from the Static Web Apps side:

As mentioned above, our images have npm@6.14.15 pre-baked into them with no explicit way to snap to a specific version. One thing I tested was using the PRE_BUILD_COMMAND environment variable to run the npm install -g npm@{version} command right before the oryx build command takes place, allowing the container running the build image to be updated with the latest (or a specific) version of npm, depending on what the user would like to opt into.

From the SWA GitHub Action, I can see in the actions.yml file that there are api_build_command and app_build_command inputs that reference Oryx and running custom commands, but I'm not sure if that's leveraging any of the Oryx *_BUILD_COMMAND environment variables or something separate. I'm not sure if it's too niche to provide the users with an npm_version input here to allow them to provide latest or a specific version (specifying in the description that the default, if not provided, is 6.14.15), or we could introduce a separate input that's explicitly about running a command before oryx build. This seems to depend on (1) what those existing inputs do, and (2) the messaging of this to users 😀.

I'm not sure about the other mechanisms for deploying SWAs (Azure Portal, VS Code, CLI, etc.), but wherever a container is using the Oryx build image and we have the ability to set environment variables within the container, we should be OK to set this PRE_BUILD_COMMAND variable and update version of npm used within the container.

Does this sound like a feasible solution or is there another route we'd like to take? We can keep investigating from the Oryx side for other ways to support this if needed.

[cormacpayne]

@simonaco @anthonychu @Reshmi-Sriram -- as an update: Oryx just released an update to our CLI that now supports detecting the engines field in a user's package.json file, and more specifically, parsing a version spec that's provided for the npm property within this field.

For example, if the user has the following in their package.json file:

{
    "engines": {
        "npm": ">=7.0.0"
    }
}

Oryx will add a snippet to the build script generated that runs npm install -g npm@'>=7.0.0' to ensure that the user has the latest version of npm installed on the build container that meets this criteria, which should resolve this issue without needing any additional work from the SWA side.

[johnnyreilly]

Thanks @cormacpayne - I ended up blogging this approach here (using node rather than npm)

https://blog.johnnyreilly.com/2022/05/28/azure-static-web-apps-node-16-oryx

[thomasgauvin]

Can we close this issue as resolved? @Reshmi-Sriram

[Reshmi-Sriram]

Feel free to re-open in case of further discussions!