Uh oh!
There was an error while loading. Please reload this page.
chore(deps): update all non-major dependencies - #446
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
|
9c4e39b to
5bfebeaCompare5bfebea to
7804f68Compare7804f68 to
2d975ffCompare2d975ff to
0104ff1Compare0104ff1 to
8120e32Compare8120e32 to
5ec9f5eCompare5ec9f5e to
efcb3b7Compareefcb3b7 to
1a61aecCompare1a61aec to
cf8e7f8Comparecf8e7f8 to
2b13cf8Compare6132302 to
360e116Compare360e116 to
aa97a8bCompareaa97a8b to
714cf9dCompare714cf9d to
bdbb60cComparebdbb60c to
9343bf3Compare9343bf3 to
fb7fea7Comparefb7fea7 to
556aaaeComparecommit: |
Uh oh!
There was an error while loading. Please reload this page.
| "@nuxt/image": "^1.11.0", | ||
| "@nuxt/scripts": "workspace:*", | ||
| "@nuxt/ui": "4.0.0", | ||
| "@nuxt/ui": "4.2.1", |
There was a problem hiding this comment.
| "@nuxt/ui": "4.2.1", | |
| "@nuxt/ui": "^4.2.1", |
The @nuxt/ui dependency is pinned to 4.2.1 without a caret, which is inconsistent with all other dependencies in this file that use flexible versioning with the ^ prefix.
View Details
Analysis
Inconsistent version pinning for @nuxt/ui dependency
What fails: docs/package.json line 20 specifies @nuxt/ui as pinned version 4.2.1 (without caret prefix), while all 13 other dependencies use caret versioning (^) for flexible version constraints within the major version.
How to reproduce:
cat docs/package.json | grep -A 15 '"dependencies"'Result: Shows "@nuxt/ui": "4.2.1" (pinned) while all surrounding dependencies have caret prefix:
"@nuxt/content": "^3.8.2""@nuxt/fonts": "^0.12.1""@nuxthq/studio": "^2.2.1"- All other 10 dependencies also use
^prefix
Expected behavior: According to npm semantic versioning, caret versioning allows compatible updates (minor/patch versions) within a major version. The project consistently uses this pattern for all other dependencies, so @nuxt/ui should be ^4.2.1 to match the established convention and allow patch/minor updates like other dependencies.
Root cause: Automated dependency update (Renovate bot commit 0b37709) preserved the previous pinned format when bumping the version from 4.0.0 to 4.2.1, rather than applying the project's standard caret versioning pattern used throughout the file.
| "posthog-js": "^1.0.0" | ||
| "@types/youtube": "^0.1.2", | ||
| "@unhead/vue": "^2.1.2", | ||
| "posthog-js": "^1.321.2" |
There was a problem hiding this comment.
| "posthog-js": "^1.321.2" | |
| "posthog-js": "^1.0.0" |
The posthog-js peer dependency constraint changed from ^1.0.0 to ^1.321.2, which is unusually restrictive and appears unintentional given the patch version bump in devDependencies (1.321.1 → 1.321.2).
View Details
Analysis
Overly restrictive posthog-js peer dependency breaks backward compatibility
What fails: The posthog-js peer dependency constraint in package.json was changed from ^1.0.0 to ^1.321.2 (commit 1536ad2), restricting supported versions to 1.321.2+ and rejecting all prior versions (1.0.0-1.321.1) that would previously install.
How to reproduce:
# User has posthog-js 1.200.0 installed (legitimate version under old ^1.0.0 constraint)
npm install @nuxt/scripts
# After update, npm now rejects this version because 1.200.0 does not satisfy ^1.321.2Result: npm/pnpm install fails with: "posthog-js@1.200.0 not satisfied by ^1.321.2"
Expected: The peer dependency should remain at ^1.0.0 (or similar permissive constraint) since:
- Code only uses
posthog.init()and basic config options (api_host,capture_pageview,disable_session_recording) available since 1.0.0 - The devDependency update was only a patch bump (1.222.0 → 1.321.2), not a major version requiring API changes
- Peer dependencies should be permissive to maximize compatibility
- Semantic versioning guidance indicates patch/minor version updates within the same major version should be backward compatible
This change appears to be an error from automated dependency update tooling (Renovate) that applied the same pinpoint version to both devDependencies and peerDependencies.
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. |
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
This PR contains the following updates:
^3.4.0→^3.4.1^7946.0.0→^7946.0.16^3.58.1→^3.65.4^1.9.21→^1.9.22^1.9.0→^1.9.22^7.7.1→^7.8.0^0.1.0→^0.3.0v0.0.9-mp→v0.0.9^0.5.3→^0.5.424→24.19.0^0.142.0→^0.143.011.19.0→11.20.0^1.409.5→^1.410.61.412.0(+5)^1.0.0→^1.410.61.412.0(+5)^6.27.0→^6.28.0Release Notes
nuxt/devtools (@nuxt/devtools-kit)
v3.4.1Compare Source
🐞 Bug Fixes
View changes on GitHub
Hebilicious/reproduire (Hebilicious/reproduire)
v0.0.9Compare Source
compare changes
unjs/magicast (magicast)
v0.5.4Compare Source
🐞 Bug Fixes
View changes on GitHub
actions/node-versions (node)
v24.19.0: 24.19.0Compare Source
Node.js 24.19.0
v24.18.1: 24.18.1Compare Source
Node.js 24.18.1
v24.18.0: 24.18.0Compare Source
Node.js 24.18.0
v24.17.0: 24.17.0Compare Source
Node.js 24.17.0
v24.16.0: 24.16.0Compare Source
Node.js 24.16.0
v24.15.0: 24.15.0Compare Source
Node.js 24.15.0
v24.14.1: 24.14.1Compare Source
Node.js 24.14.1
v24.14.0: 24.14.0Compare Source
Node.js 24.14.0
v24.13.1: 24.13.1Compare Source
Node.js 24.13.1
v24.13.0: 24.13.0Compare Source
Node.js 24.13.0
v24.12.0: 24.12.0Compare Source
Node.js 24.12.0
v24.11.1: 24.11.1Compare Source
Node.js 24.11.1
v24.11.0: 24.11.0Compare Source
Node.js 24.11.0
v24.10.0: 24.10.0Compare Source
Node.js 24.10.0
v24.9.0: 24.9.0Compare Source
Node.js 24.9.0
v24.8.0: 24.8.0Compare Source
Node.js 24.8.0
v24.7.0: 24.7.0Compare Source
Node.js 24.7.0
v24.6.0: 24.6.0Compare Source
Node.js 24.6.0
v24.5.0: 24.5.0Compare Source
Node.js 24.5.0
v24.4.1: 24.4.1Compare Source
Node.js 24.4.1
v24.4.0: 24.4.0Compare Source
Node.js 24.4.0
v24.3.0: 24.3.0Compare Source
Node.js 24.3.0
v24.2.0: 24.2.0Compare Source
Node.js 24.2.0
v24.1.0: 24.1.0Compare Source
Node.js 24.1.0
v24.0.2: 24.0.2Compare Source
Node.js 24.0.2
v24.0.1: 24.0.1Compare Source
Node.js 24.0.1
oxc-project/oxc (oxc-parser)
v0.143.0💥 BREAKING CHANGES
067da8cast: [BREAKING] Store single parameter inTSIndexSignature::parameter(#25154) (camc314)1bdedd1ast: [BREAKING] IntroduceExportDeclaration,ExportFromDeclaration(#25095) (camc314)c917f20ast: [BREAKING] IntroduceArrowFunctionBodyenum (#24987) (camc314)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
PostHog/posthog-js (posthog-js)
v1.410.6Compare Source
1.410.6
Patch Changes
6d5e314Thanks @ioannisj! - Fix session replay shipping one billable recording per session rotation for tabs the user never interacts with. A session born from an idle rotation now holds its buffer until the first user interaction, then ships a recording playable from the session's start; without interaction nothing is sent — a further rotation, stop, opt-out, or page unload discards the held data instead of shipping it. An event trigger match (for example record-on-exception) also releases the hold, since it is explicit intent to record the session.(2026-08-03)
v1.410.5Compare Source
1.410.5
Patch Changes
8ec3499Thanks @felipeatom! - Fix selector-widget surveys being abruptly removed while open when their trigger element is unmounted from the DOM (e.g. a dropdown or menu that hosts the trigger closes). The survey is now kept in place while open and only torn down once the user has closed it. Also fixes a related leak where, if the selector resolved to a different element while the survey was open, the old element's click listener was never removed and kept dispatching the show-widget event for the lifetime of the page.(2026-08-03)
v1.410.4Compare Source
v1.410.3Compare Source
1.410.3
Patch Changes
662fb4cThanks @christiaan-ph! - Conversations widget: bullet and numbered lists in a support reply now keep their markers on host pages with an aggressive CSS reset (for example Tailwind preflight'sol, ul { list-style: none }). The widget renders into the host page's DOM, so the list style is now set inline on<ul>,<ol>, and<li>rather than left to the page's own styles.(2026-08-03)
v1.410.2Compare Source
v1.410.1Compare Source
1.410.1
Patch Changes
0854095Thanks @marandaneto! - Prevent the inline canvas recording worker from requesting an unusable source map from its blob URL.(2026-08-03)
eb0a793]:Configuration
📅 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.