Use npm to manage tool dependencies #240
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Some of the assets use tools sourced from the npm software registry. Previously, the version of the tools used was not controlled. This was problematic because: - A different version of the tool may be used on the contributor's machine than on the CI runner, resulting in confusing failures. - The project is immediately subject to disruption or breakage resulting from a release of the tool. --- These tools were installed via either of the following methods: `npx <pkg>` This approach has the following behaviors of interest: https://docs.npmjs.com/cli/v8/commands/npx#description > If any requested packages are not present in the local project dependencies, then they are installed to a folder in the npm cache, which is added to the PATH environment variable in the executed process. > Package names provided without a specifier will be matched with whatever version exists in the local project. Package names with a specifier will only be considered a match if they have the exact same name and version as the local dependency. This means that the version used was: 1. Whatever happens to be present in the local cache 2. The latest available version if it is not already present `npm install --global <pkg>` The latest available version of the package is used. --- ` The new approach is to specify the version of the tools via the standard npm metadata files (package.json + package-lock.json). This approach was chosen over the `npx <pkg>@<version>` alternative for the following reasons: - Enables automated updates via Dependabot PRs - Enables automated vulnerability alerts - Separates dependency management from the asset contents (i.e., no need to mess with the taskfile or workflow on every update) - Matches how we are already managing Python dependencies (pyproject.toml + poetry.lock)
We are now standardizing on the use of npm to manage tool dependencies of the assets. There is one drawback to that approach, which is that it requires the addition of the npm metadata files to the repository (if not already present). Two more files are not of any concern for the average Arduino tooling project. However, the "Sync Labels" workflow is already in widespread usage in other types of official Arduino projects. In some projects (e.g., Arduino libraries), where the contents are intended to be very approachable to less advanced users, the added files may be considered problematic, especially since, unlike all the other workflows that were candidates for npm-managed tools, the "Sync Labels" workflow did not require the addition of any files other than the GitHub Actions workflow (the others also require a taskfile at minimum). For this reason, the previous lightweight version of "Sync Labels" is retained, but another version added for use in projects where the dependency management is desired.
per1234
added
type: enhancement
umbynos
approved these changes
Jun 23, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some of the assets use tools sourced from the npm software registry.
Previously, the version of the tools used was not controlled. This was problematic because:
These tools were installed via either of the following methods:
npx <pkg>This approach has the following behaviors of interest:
https://docs.npmjs.com/cli/v8/commands/npx#description
This means that the version used was:
npm install --global <pkg>The latest available version of the package is used.
The new approach is to specify the version of the tools via the standard npm metadata files (
package.json+package-lock.json). This approach was chosen over thenpx <pkg>@<version>alternative for the following reasons:pyproject.toml+poetry.lock)Resolves #213