actions

I noticed that node.yml workflow, for each matrix configuration, the UUT (project) is built with the selected node version, then the test suite is run on the same node runtime. ie: However, in real life, a dev publishes an NPM package built with one node runtime (say v40), and when users include that package in their projects, they build their projects on their own runtime (say v33), and release the product to end users who run it on a variety or runtimes (say v1-99), ie: Is it valid to assert that if a projects builds on version X and passes the tests on version X for any value of X, then the released package, built on version Y will run correctly on any runtime version from v1-99 ? Shouldn't the release candidate package be tested against all the supported runtimes? Thanks

When running with type , it doesn't seem likely that the user is interested in odd-numbered majors except current. For example, running today with a range of , the results of deprecated v17 seems irrelevant. @ljharb If you think this sounds reasonable I could take a stab it at

I've just found that the deprecation warning is displayed in the GitHub Actions workflows for eslint-plugin-import. https://github.com/import-js/eslint-plugin-import/actions/runs/3768297080/jobs/6406611863 !image Warning: The command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ I believe the following code in this repository has something to do with it, is that right? https://github.com/ljharb/actions/blob/d90a9d324b9dac81dc3fd2a93f98118c9db1e515/node/run/index.js#L36-L38 https://github.com/ljharb/actions/blob/6c38ef617880bbadc9f65479221121d69a51081e/node/install/index.js#L62-L64