chore(deps): update all non-major dependencies - #315
Conversation
Branch automerge failureThis PR was configured for branch automerge. However, this is not possible, so it has been raised as a PR instead.
|
|
Important Review skippedIgnore keyword(s) in the title. ⛔ Ignored keywords (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Note Free review on us!CodeRabbit is offering free reviews until Wed Jan 15 2025 to showcase some of the refinements we've made. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
90156eb to
bedc1f9
Compare
62b572f to
20b2efc
Compare
20b2efc to
b0f42e3
Compare
|
All alerts resolved. Learn more about Socket for GitHub. This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
00ea2cc to
1f1225c
Compare
1a7bdfb to
d1cfb3a
Compare
3a44d05 to
e5b1cc1
Compare
d087437 to
8a59397
Compare
cba75b4 to
2d701f7
Compare
37c49a1 to
637d6da
Compare
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
This PR contains the following updates:
1.16.0→1.17.024.12.4→24.13.3v2.0.1→v2.2.0v0.1.0→v0.2.0v0.5.4→v0.5.51.1.0→1.4.03.1.2→3.2.016.2.0→16.2.39.1.6→9.1.717.0.5→17.3.011.1.2→11.20.05.6.3→5.9.3Release Notes
nuxt/eslint (@nuxt/eslint-config)
v1.17.0Compare Source
🚀 Features
🐞 Bug Fixes
View changes on GitHub
MatteoGabriele/agentscan-action (MatteoGabriele/agentscan-action)
v2.2.0Compare Source
What's Changed
Full Changelog: MatteoGabriele/agentscan-action@v2.1.0...v2.2.0
v2.1.0Compare Source
What's Changed
Full Changelog: MatteoGabriele/agentscan-action@v2.0.1...v2.1.0
danielroe/provenance-action (danielroe/provenance-action)
v0.2.0Compare Source
compare changes
🚀 Enhancements
📖 Documentation
🏡 Chore
✅ Tests
🤖 CI
❤️ Contributors
v0.1.1Compare Source
compare changes
🚀 Enhancements
📖 Documentation
@mainconstraint for example (237ceea)❤️ Contributors
danielroe/uppt (danielroe/uppt)
v0.5.5Compare Source
What's Changed
7bcfb53)Full Changelog: danielroe/uppt@v0.5.4...v0.5.5
mmkal/expect-type (expect-type)
v1.4.0Compare Source
What's Changed
thisParameterby @aryaemami59 in #204.branded.inspectto view deep prop types by @mmkal in #113Full Changelog: mmkal/expect-type@v1.3.0...v1.4.0
v1.3.0Compare Source
What's Changed
Full Changelog: mmkal/expect-type@v1.2.2...v1.3.0
v1.2.2Compare Source
7d6fa420c9d8c27ff4f4d1149186v1.2.1Compare Source
0c5a05dv1.2.0Compare Source
What's Changed
❗
toMatchTypeOfis now deprecated. There are no plans to remove it any time soon, so it's not critical to immediately remove usages, but if you want to avoid squigglies in IDEs complaining about deprecations, here's what you should do:If you have an assertion like this:
There are a few options for upgrading it. The easiest is
toExtendwhich is identical to the behaviour oftoMatchTypeOf:This will work in all cases. But, there is now a stricter option that will work in many cases and be slightly more likely to catch things like
readonlyproperties matching:But, as the name suggests, this will only work on plain object types, it will fail for union types, and some other complex types.
If you have code like this:
You'll need to use
typeofbecausetoExtendandtoMatchObjectTypedo not accept argumentsFull Changelog: mmkal/expect-type@v1.1.0...v1.2.0
unjs/get-port-please (get-port-please)
v3.2.0Compare Source
compare changes
🚀 Enhancements
🩹 Fixes
169.254.0.0/16range to not allowed hostnames (#101)🏡 Chore
✅ Tests
console.logimplementation in error tests (#104)🤖 CI
❤️ Contributors
sindresorhus/globby (globby)
v16.2.3Compare Source
.gitignorerules5775ffbv16.2.2Compare Source
gitignoreoption8bf8f54v16.2.1Compare Source
gitignoreignoring an entire checkout under an anchored ancestor path (#277)e7bd988typicode/husky (husky)
v9.1.7Compare Source
What's Changed
New Contributors
Full Changelog: typicode/husky@v9.1.6...v9.1.7
lint-staged/lint-staged (lint-staged)
v17.3.0Compare Source
Minor Changes
#1825
16b3f74- It is now possible to run multiple tasks in parallel for a single glob by configuring it with an array of tasks (which run sequentially), and then placing another array inside it (where the tasks will run in parallel). The following demonstrates the order tasks will start in:{ "*.ts": ["first", "second", ["third", "third"], "fourth"] }As a concrete example, lint-staged's own configuration is:
which means:
oxfmt --check --no-error-on-unmatched-pattern lib/index.jsoxlint --no-error-on-unmatched-pattern lib/index.js*.tsfiles are staged, runtscwithout appending any argumentsPatch Changes
15f7e53- During an in-progress merge, files that are unchanged from the branch being merged are now skipped. Technically, files are only included if there are staged changes against bothHEADandMERGE_HEAD.v17.2.0Compare Source
Minor Changes
#1823
ee156cc- The chunking of tasks based on maximum command line argument length has been re-implemented to be more precise. Now the chunking happens based on the final generated command string, instead of just the list of staged files like previously. This benefits mainly Windows platforms and function commands like:Where the spawned command is literally
"tsc"without any extra arguments. Previously, this was still chunked when a lot of files were staged. Now, it probably won't be chunked because the length of the command is just three letters.Also, native JavaScript/Node.js function tasks won't be chunked at all, when previously they were run multiple times when chunked:
v17.1.1Compare Source
Patch Changes
a626a9f- It's now possible to set--max-arg-length=Infinityto effectively disable chunking of tasks based on the number of staged files. The parsing and validation of the numeric CLI options--max-arg-lengthand--concurrencyhas been improved.v17.1.0Compare Source
Minor Changes
#1816
7568d4f- The console output of lint-staged has been simplified so that there's less interactive spinners and more explicit messages like "Started…" -> "Done!". The primary purpose of this was to removeListr2, a very large dependency.Before:
Size of
node_modules/after installing:1561.7 kBwith 29 packages.Fancy interactive spinners, but output dynamically changes:
After:
Size of
node_modules/after installing:974.0 kBwith 5 packages (37.6 % smaller, 82.7 % less transitive dependencies).Simpler but more explicit output:
Patch Changes
#1816
c19079d- Try to restore hidden unstaged changes when using--no-revert.#1818
efb23a2- Console output colors are enabled/disabled more consistently.#1818
26112a1- Failed JS function tasks now properly kill other tasks, unless--continue-on-erroris used. Previously their failure didn't affect other tasks.v17.0.8Compare Source
Patch Changes
#1809
179b437- Fix lint-staged discarding the ongoing merge conflict status (.git/MERGE_HEAD) when using the--hide-unstagedor--hide-alloptions.#1811
3d0b2c0- Fix issues with Git commands that are successful but also emit warnings tostderr, by ignoring thestderroutput completely when the process exits with code 0. This was the behavior when usingnano-spawnandexeca, but when switching totinyexecin 16.3.0 bothstdoutandstderrwere used as interleaved output.v17.0.7Compare Source
Patch Changes
e692e58- Update dependencytinyexec@^1.2.4.v17.0.6Compare Source
Patch Changes
#1803
bdf2770- Run all tests with Deno, in addition to Node.js and Bun.#1796
7508272- Fix performance regression of lint-staged v17 by going back to usinggit addto stage task modifications. This was changed togit update-index --againin v17 for less manual work, but unfortunately theupdate-indexcommand gets slower in very large Git repos.#1797
7b2505a- This version of lint-staged uses the new staged publishing for npm packages feature. Releases are already published from GitHub Actions with trusted publishing, but now an additional approval with two-factor authentication is also required.#1802
321b0a9- Downgrade dependencytinyexec@1.2.2to avoid issues in version 1.2.3.pnpm/pnpm (pnpm)
v11.20.0: pnpm 11.20Compare Source
Minor Changes
Security fix. Affects projects using
namedRegistrieson pnpm 11.1.0–11.19.x. It is semi-breaking for those projects — see "If you use named registries" below.The lockfile recorded no marker for which registry a package came from. Packages were keyed by
name@versionalone, and entry lookup went throughrefToRelative(ref, name), so a dependency you declared against one registry could be satisfied by an entry that was actually resolved from another. When two registries served the same name and version, both collapsed onto a singlepackages:entry and whichever resolved first decided the tarball every consumer got.That is a package-substitution risk: a package you expect from your private registry could be installed from a different registry that publishes the same name and version, and the lockfile recorded nothing that would let you tell.
Packages resolved from a named registry are now recorded under registry-qualified keys (
<name>@<registryName>:<version>, e.g.foo@work:1.0.0), so each registry gets its own entry and the lockfile pins which one a dependency came from.The lockfile format version is unchanged. Registry-qualified keys appear only for packages resolved from a named registry, so a project that does not use
namedRegistriessees no difference, and older pnpm versions keep reading the file.If you use named registries
Your next non-frozen install re-keys those entries, which shows up as a lockfile diff. Commit it — that diff is the fix being applied. Review it: an entry that moves to a registry you did not expect is worth investigating.
Everyone working on the project should be on this version or newer before you do. An older pnpm reads the re-keyed lockfile fine — frozen installs are unaffected — but it does not produce registry-qualified keys itself, so any install that updates the lockfile writes those entries back to the old shape, and the next install on a current pnpm re-qualifies them. The result is a lockfile that flips back and forth, and while it is in the old shape the project is exposed again. Because the lockfile format version is deliberately unchanged, pnpm cannot detect this and warn you about it.
There is no setting to keep the old behavior: the old shape is the vulnerability.
Tarball URLs that follow the standard registry layout are no longer written to the lockfile for named-registry packages; they are recomputed from the
namedRegistriessetting on demand.To use named registries, map your aliases in
pnpm-workspace.yaml:New built-in
npmjs:aliasnpmjs:now resolves tohttps://registry.npmjs.org/with no configuration, alongside the existinggh:alias for GitHub Packages. It pins a dependency to the public registry even whenregistrypoints elsewhere, such as an internal proxy:{ "dependencies": { "left-pad": "npmjs:^1.3.0" } }npm:cannot do this — it is the alias protocol (npm:<name>@<range>) and resolves through whateverregistrypoints at.If you mirror or proxy npmjs, point the alias at your mirror:
Built-in registry URLs are also the prefixes a lockfile's recorded tarball URL is matched against when pnpm verifies a package. Without the override, an entry whose tarball URL is on
registry.npmjs.orgis verified against the public registry rather than your mirror. This only affects lockfiles that record such URLs — a canonical URL for your configured registry is omitted from the lockfile and unaffected — and only when a tarball-URL,minimumReleaseAge, ortrustPolicycheck runs. Overriding the alias is the same escape hatch GHES users already have forgh.Every alias the lockfile references must stay in
namedRegistries: reading an entry whose alias is gone fails withERR_PNPM_MISSING_NAMED_REGISTRYrather than silently falling back to the default registry, since that would fetch a different package. Renaming an alias re-resolves the packages that used it.Named registry aliases that shadow a reserved dependency specifier prefix (
file,link,workspace,runtime,npm,jsr, ...) are now rejected withERR_PNPM_RESERVED_NAMED_REGISTRY_NAMEinstead of being silently shadowed by the corresponding resolver.pnpm licensesandpnpm sbomnow keep the two artifacts apart as well: license records carry the registry alias, and SBOM components carry the purlrepository_urlqualifier.Patch Changes
An empty
http-proxy,https-proxy,proxy, orno-proxyvalue — from the.npmrc,pnpm-workspace.yaml, the CLI, or theHTTP_PROXY/HTTPS_PROXY/PROXY/NO_PROXYenvironment variables — no longer fails the install withERR_PNPM_INVALID_PROXY. Empty settings read as unset, so a shell exportingHTTP_PROXY=disables the proxy, and an emptyproxy=in the.npmrcno longer suppressesHTTPS_PROXY#13533.proxy=falsein the.npmrcorproxy: falseinpnpm-workspace.yamlnow turns proxying off instead of being read as a proxy host namedfalse.falseandnullonhttps-proxy/http-proxy/no-proxyread as unset, and on the command line they are ordinary host names, since a flag carries its value verbatim.The env lockfile no longer pins
@pnpm/exealongsidepnpmwhen the wanted pnpm version is 12 or newer. From v12 the unscopedpnpmpackage is itself the native executable, so@pnpm/exeis not published for it and resolving it would fail. The engine identity check now verifies the native binary through whichever package ships it.lexCompareandnerfDartare now published as@pnpm/text.ordinal-comparatorand@pnpm/config.registry-auth-key. Use these instead of@pnpm/util.lex-comparatorand@pnpm/config.nerf-dart.Fixed the order in which pnpm matches a lockfile's recorded tarball URL against known registry URLs. Two registry URLs of equal length were previously ordered arbitrarily, so which one a tarball URL matched could differ between runs.
Dependency resolution is faster: package metadata is now filtered once per packument instead of once per dependency edge when
minimumReleaseAgeis active, and parsed semver versions and ranges are reused instead of re-parsed on every comparison.Security:
pnpm rebuildnow refuses a lockfile whosepackageskey carries a path traversal in the package name (e.g.../../../escaped@1.0.0), instead of running that package's lifecycle scripts and linking its bins in a directory outside the virtual store. Such a name is rejected withERR_PNPM_INVALID_DEPENDENCY_NAME.Platinum Sponsors
Gold Sponsors
v11.19.0: pnpm 11.19Compare Source
Minor Changes
pnpm loginno longer requires an interactive terminal when the registry supports web-based login: without a TTY it prints the authentication URL (skipping the QR code and the "Press ENTER to open the URL in your browser" prompt) and polls the registry until the browser approval completes. Only the classic username/password login still fails withERR_PNPM_LOGIN_NON_INTERACTIVEin a non-interactive terminal.The
save-prefixsetting now accepts=: newly added dependencies are saved with an explicit=operator (=1.2.3) instead of the setting being silently treated as the default^.Patch Changes
allowBuildsentries can now approve git-hosted packages that pnpm downloads as a tarball, such asgithub:dependencies (which are fetched fromcodeload.github.comrather than cloned), by their repository URL without the resolved commit hash. This matches the hashlessgit+matching already supported for cloned git dependencies. For example:This approves the package whether pnpm clones it or downloads a tarball, so the entry no longer has to be updated every time the pinned commit changes. GitLab and Bitbucket tarball downloads are matched the same way. Approving or denying a specific resolved commit by its full tarball dep path continues to work.
pnpm outdated --include-github-actionsno longer blocks on an interactive git credential prompt when a workflow uses a private action repo.Prevented
minimumReleaseAgefrom replacinglatestwith a SemVer-greater version than the registry tag target #13034.Fixed empty
bundledDependenciesandbundleDependenciesarrays causing nondeterministic lockfile changes. See #13123.The install summary no longer prints
(X is available)when the registry'sdist-tags.latestis still held back by the activeminimumReleaseAgepolicy. The hint only ever names the actual latest tag, so an immature latest suppresses the hint instead of advertising the version pnpm just refused to install #11698.pnpm updatekeeps the explicit=operator of an exact version pin: a dependency saved as=3.5.1now updates to=3.5.2instead of the bare3.5.2. See #13168.Preserve a workspace dependency's
link:entry when a run does not target it — e.g.pnpm update <other-pkg>(with or without--recursive), or a plain install after a root/catalog dependency change — withinjectWorkspacePackages, instead of spuriously rewriting it to a peer-suffixedfile:protocol. See #10433.Workspace dependencies declared with a relative path (e.g.
"foo": "workspace:../foo") are no longer silently dropped from the workspace projects graph, so--filterselection and the topological order of recursive commands take them into account.Platinum Sponsors
Gold Sponsors
v11.18.0: pnpm 11.18Compare Source
Minor Changes
Fixed an installed optional dependency being left without one of its own required dependencies. When a package reached through
optionalDependenciesis installable on the current system but one of its regulardependenciesis not, a lockfile-based install skipped that dependency and installed the parent anyway, so importing the parent failed withMODULE_NOT_FOUND. The dependency is now installed, and an install-check warning reports the incompatibility. A dependency is still only skipped when every path to it is optional, or when the package that pulls it in was itself skipped #13286.pnpm setupnow appendsPNPM_HOMEand the global bin directory to the GitHub Actions environment files (GITHUB_ENVandGITHUB_PATH), so later steps in the same job can runpnpm add --globaland other global commands #9191.Added support for
publishConfig.name, which publishes a package under a different name than the one its manifest carries in the workspace. It is for a project whose published name is already taken by a sibling project, which otherwise has to be renamed by a build step just before publishing. Only the published artifact is renamed — dependents,pnpm-lock.yaml, and release tooling keep addressing the project by its manifest name — and the new name reaches the packed manifest, the tarball filename, and everything that addresses the package at the registry: the already-published check ofpnpm publish -r, its registry selection, and the release-planning probes ofpnpm change statusandpnpm version -r#13345.pnpm self-updateno longer takes any instruction from the project it is run in:.npmrcorpnpm-workspace.yamlcan no longer redirect the download or attach credentials to it, and the project's default.pnpmfile.(c|m)jsis no longer loaded. Pnpmfiles from trusted sources (thepnpmfilesetting, the global pnpmfile, config dependencies) still apply.minimumReleaseAgesettings inpnpm-workspace.yamlno longer affectself-update. They still govern the project's own dependencies; forself-updatethe cooldown now comes from the built-in default, your global config, aPNPM_CONFIG_*environment variable, or a command-line flag. This fixesself-updatefailing inside a workspace that raises the cutoff while succeeding everywhere else, and stops a repository from either waiving the cooldown or keeping you on an outdated pnpm by raising it.trustPolicysettings and toci: a project can no longer weaken the trust check that guards the pnpm download, nor re-enable the confirmation prompt that a CI run suppresses.When
self-updaterefuses a version that is younger than the cutoff, an interactive run now offers to update anyway; non-interactive runs still fail. CI never prompts, even on a runner that attaches a TTY.Patch Changes
Fixed
pnpm licenses listto report every version when the same package is installed under multiple aliases pnpm/pnpm#13438.Sort
pnpm dedupe --checksnapshot changes for stable output across pnpm implementations.Strip Unicode formatting characters from registry- and manifest-derived terminal output.
Speed up installs after compatible catalog or direct dependency range changes by retaining the locked version without resolving the dependency graph again.
Speed up installs after safe override changes by reusing unambiguous compatible dependency resolutions, pruning obsolete dependencies, applying independent replacements and removals together, and handling parent-scoped
"-"overrides without full lockfile resolution.Installing a local
file:directory dependency with the global virtual store enabled no longer fails withTypeError: Cannot read properties of undefined (reading 'split')#13335.Local directory dependencies —
file:directories and injected workspace packages — now get a global-virtual-store slot of their own per project. They used to share one slot across every project that depended on a directory of the same name, so a project could end up linked to another project's copy of the dependency.The
Workspacecolumn ofpnpm update --interactivenow falls back to the project's path when itsnameis only whitespace, as it already did for a missing or empty one — all three render an equally blank label otherwise.Checking GitHub Actions dependencies for updates is now opt-in for every command. Neither
pnpm outdatednorpnpm updatereads the workflow files unless--include-github-actionsis passed orupdate.githubActionsis set totrueinpnpm-workspace.yaml. Reading them runsgit ls-remoteagainst every referenced repository, which fails in environments where GitHub is not reachable the way pnpm assumes (a GitHub Enterprise Server, a custom certificate authority, or an offline network) #13254.pnpm outdatedaccepts the--include-github-actionsoption too.pnpm update --interactivenow measures its table in terminal columns rather than in characters. A package name, workspace name, or version containing wide characters (CJK, most emoji) no longer knocks its row's columns out of line with the rest of the group, and a wide character in a version no longer aborts the command withSubject parameter value width cannot be greater than the container width#13357.The
Workspacecolumn ofpnpm update --interactiveis more informative in two cases. A dependency outdated at the same version in several workspace projects is offered as one choice, since selecting it updates every project — that choice now names all of them instead of only the first. And a workspace project without anameis now labelled with its path rather than left blank, so several unnamed projects can be told apart.An auto-installed optional peer is no longer hoisted at a version the workspace root's own dependency on that package excludes.
resolvePeersFromWorkspaceRootalready made the workspace root's specifier decide which version a missing required peer is installed at; the optional-peer picker ignored it and always took the highest version present anywhere in the graph. In a workspace whose root pinspostcss: 8.5.10, an importer that depends onwebpackand declares nopostcssof its own gotpostcss@8.5.22hoisted forterser-webpack-plugin's optionalpostcsspeer, leaving twopostcss@8.5.xinstances in the graph #13320.overridesnow also govern peers that pnpm auto-installs. Previously an override only rewrote dependencies declared in a manifest, so a peer nobody declares — installed becauseautoInstallPeersis on — resolved against its declared peer range and could bring in a second copy of the very package the override pinned. For example, withoverrides: { react: npm:react@19.2.0 }and a lonelucide-reactdependency, pnpm installedreact@18.3.1; it now installs the pinnedreact@19.2.0#13320.Under
resolvePeersFromWorkspaceRoot, a workspace root dependency declared withlink:orfile:(or the path form ofworkspace:, such asworkspace:../pkg) now satisfies another project's missing peer dependency at the linked package's own version, instead of being hoisted as a path. Those specifiers are relative to the project that declares them, so the same specifier reached a different directory — or none — from the project the peer was hoisted into, leaving a broken link. The root now has the same authority over the peer as it has when it declares the package with a version range [#13373](https://redirect.giConfiguration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR was generated by Mend Renovate. View the repository job log.