adobe / helix-deploy

A multi-cloud deployment tool for serverless functions running on AWS Lambda, Adobe I/O Runtime, Azure Functions, and Google Cloud Functions. Write once, run everywhere.
Apache License 2.0
11 stars 15 forks source link

Enable reading `.node-version` (or similarly structured) file to read the node version #664

Open justinedelson opened 4 months ago

justinedelson commented 4 months ago

Expected Behaviour

It is frequently important to have the runtime node version match the version used locally and in CI (e.g. to run tests). Similarly to how the setup-node or asdf-vm/actions/install actions work in GitHub Actions, it should be possible for hedy to read the node version from a file so that the following are controlled in one place:

Proposed Syntax

node-version-file CLI argument and nodeVersionFile package configuration should be able to contain a relative file path. If present and the file contains a parseable value, this should be used as the node version. If the value is a simple integer, that's the node version. If the value contains a two or three segment version (i.e. 20.1.2) then only the first segment is used.

Similar to the setup-node action, if both node-version-file and node-version are configured, node-version is used.

tripodsan commented 4 months ago

I think this can be solved through https://docs.npmjs.com/cli/v6/configuring-npm/package-json#engines

justinedelson commented 4 months ago

I think engines means something slightly different -- that is intended to represent a range of versions that can be used whereas .node-version (when used with a version manager), setup-node/node-version and node-version in hedy configuration say "this is the version to use"

tripodsan commented 4 months ago

but using package.json as node version would work: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#node-version-file

so you can keep the build version (engines) and the deploy version (wsk.node-version) close together in the same file.

justinedelson commented 4 months ago

Ah, I understand now. Yes, that provides some locality. And TBH if it was just a matter of GitHub Actions + hedy this wouldn't be necessary since you can extract the version set up by the setup-node action as an output and use it to generate a HLX_NODE_VERSION environment variable.

But this leaves local execution out. I clarified this in my original message.