Conversation
The minimumFrontendPackageAgeDays parameter defaulted to 1 and was always passed as a command line argument, which takes precedence over every configuration source of npm, pnpm and bun. A project that configures min-release-age in .npmrc got the Vaadin default instead, so `mvn vaadin:build-frontend` and a manually run `npm install` disagreed on which package versions are allowed. The parameter is now unset by default. When nothing is configured on the Vaadin side, the package manager is asked what it resolves for its own minimum release age setting (`config get` for npm and pnpm, bunfig.toml for bun) and no argument is passed when it already has one. The one day default applies only when neither is configured.
Contributor
The parameter type changed from int to Integer, which the javadoc build flags as a reference that cannot be resolved.
Reading the minimum release age used `config get <key>` while the registry lookup already ran `config ls --json`, which resolves the same configuration and contains every key. Both now share getResolvedConfiguration, so there is a single way to ask npm or pnpm what it resolves for a directory, and no string parsing of the tool output is needed to tell a configured value from an unset one.
resolveMinimumFrontendPackageAgeDays returned 0 both for a check that is explicitly disabled and for one the package manager already handles itself, and the caller repeated the same check to know whether to ask npm for its version at all. Resolution now returns the install argument to add, or nothing, and the remaining day count method only formats a positive number of days for the package manager in use.
Detecting a minimum release age configured for bun meant parsing bunfig.toml by hand, as bun has no command for printing its resolved configuration (oven-sh/bun#7140). That parser only recognized a subset of what the TOML format allows, so it could just as well miss a configured value as pick up something that is not one. Only npm and pnpm, which can both report their resolved configuration, are now asked. For bun the Vaadin default applies as before, and the documentation says so.
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
The minimumFrontendPackageAgeDays parameter defaulted to 1 and was always passed as a command line argument, which takes precedence over every configuration source of npm, pnpm and bun. A project that configures min-release-age in .npmrc got the Vaadin default instead, so
mvn vaadin:build-frontendand a manually runnpm installdisagreed on which package versions are allowed.The parameter is now unset by default. When nothing is configured on the Vaadin side, the package manager is asked what it resolves for its own minimum release age setting (
config getfor npm and pnpm, bunfig.toml for bun) and no argument is passed when it already has one. The one day default applies only when neither is configured.