Skip to content

chore(deps): update dependency typescript to v7 - #846

Open
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/typescript-7.x
Open

chore(deps): update dependency typescript to v7#846
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/typescript-7.x

Conversation

@renovate

@renovate renovate Bot commented Jul 9, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
typescript (source) ^6.0.0 → ^7.0.0 age confidence
typescript (source) ^6.0.3 → ^7.0.0 age confidence

Release Notes

microsoft/TypeScript (typescript)

v7.0.2: TypeScript 7.0.2

Compare Source

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

This tag was originally released at: https://github.com/microsoft/typescript-go/releases/tag/typescript%2Fv7.0.2

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "every weekday"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate
renovate Bot requested review from DaveHanns and l2ysho as code owners July 9, 2026 18:41
@renovate
renovate Bot force-pushed the renovate/typescript-7.x branch 4 times, most recently from a96b9e8 to 2a0e97f Compare July 13, 2026 21:20
@l2ysho

l2ysho commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

I prefer to wait with v7 for few weeks

@renovate
renovate Bot force-pushed the renovate/typescript-7.x branch 17 times, most recently from 5ce3dd7 to faa1f22 Compare July 16, 2026 21:15
@l2ysho l2ysho added the wontfix Issues that will not be worked on (invalid, outdated, out of scope...). label Jul 20, 2026 — with Claude
@renovate
renovate Bot force-pushed the renovate/typescript-7.x branch 3 times, most recently from 8311100 to 3ce1df7 Compare July 21, 2026 14:50
@renovate
renovate Bot force-pushed the renovate/typescript-7.x branch 2 times, most recently from 29937d3 to 4c23881 Compare July 29, 2026 06:55
@renovate
renovate Bot force-pushed the renovate/typescript-7.x branch 20 times, most recently from 28b83dd to 00513f7 Compare September 14, 2026 09:28
@renovate
renovate Bot force-pushed the renovate/typescript-7.x branch from 00513f7 to 013d7e1 Compare September 14, 2026 11:10
l2ysho added a commit that referenced this pull request Sep 14, 2026
@l2ysho @claude
fix(renovate): stop the pnpm version guard breaking every bot lockfil…
53b42a9 
…e update (#906)

> [!NOTE]
> **TL;DR** — fixes the always-failing `renovate/artifacts — Artifact
file update failure` job by deleting one line from `renovate.json`. No
change to `package.json`; the pnpm guard stays exactly as strict as it
is on master.

## Problem

Every open Renovate PR is red on `renovate/artifacts` ("Artifact file
update failure"), and CI then fails with `ERR_PNPM_OUTDATED_LOCKFILE` —
including on PRs that touch no lockfile at all. #855, #846, #797 and
#882 are still stuck behind this.

## Root cause

The pnpm version was pinned in **three** places, and one of them
floated:

| Place | Value |
|---|---|
| `package.json` → `packageManager` | `pnpm@11.13.0` |
| `package.json` → `devEngines.packageManager` | `11.13.0`, `onFail:
"error"` |
| `renovate.json` → `constraints.pnpm` | `^11.0.0` ← floats |

Renovate resolved its pnpm from the floating range. Once pnpm 11.13.1
shipped on 2026-07-16, that range started resolving above the guard, so
Renovate's `pnpm install` aborted and it never wrote `pnpm-lock.yaml`.
No repo commit caused this — the range drifted on its own, which is why
`git log` shows nothing. Last successful bot lockfile write: 2026-07-15
(#785, at pnpm 11.13.0).

Reproduced on **unmodified master**:

- pnpm 11.13.0 → installs fine
- pnpm 11.25.0 (what `^11.0.0` resolves to today) → `[ERROR] This
project is configured to use 11.13.0 of pnpm. Your current pnpm is
v11.25.0`

The uv locks still update correctly on the same PRs, which rules out a
network or sandbox problem in Renovate's environment.

## Changes

`renovate.json` only. `package.json` is byte-identical to master.

- **Drop `constraints.pnpm`.** This is the fix. Renovate now reads the
version from the `packageManager` field, resolves exactly `11.13.0`, and
matches the guard.
- `config:base` → `config:recommended`. Deprecated alias that Renovate
already maps to the new name. No behaviour change.
- `pinVersions: false` → `rangeStrategy: "replace"`. Renovate's
`PinVersionsMigration` already rewrote the old key to exactly this, so
behaviour is unchanged — but dropping it without the replacement would
have fallen back to the `auto` default and changed how every range
update is written.
- Add `internalChecksFilter: "strict"` explicitly. Already the default,
so no behaviour change; the three sibling repos all state it, and
stating it here keeps the intent visible if the default ever moves.

The last three align this config with `apify/crawlee`,
`apify/apify-client-js` and `apify/apify-sdk-js`, none of which declare
`constraints`.

## What this deliberately does not do

An earlier revision relaxed `devEngines.packageManager.onFail` to
`"warn"`. **That is reverted** — the guard is untouched. Two reasons:

- It was not needed. The floating `constraints` range was the whole
cause.
- `onFail` also governs the package-manager *name* check, so `"warn"`
stops blocking `npm install` at the repo root. That bypasses every
pnpm-only setting in `pnpm-workspace.yaml`: the 1-day
`minimumReleaseAge` supply-chain gate, the `allowBuilds` postinstall
allowlist, and the `@puppeteer/browsers` override.

A range (`^11.13.0`) with `onFail: "error"` also clears the guard, but
pnpm string-compares `packageManager` against
`devEngines.packageManager`, so it warns `"packageManager" will be
ignored` on every command, and corepack rejects a range outright.

## Verification

Against a standalone pnpm 11.25.0 (what Renovate resolves) and npm
11.16.0:

| Case | Result |
|---|---|
| ordinary PR branch, exact pin + `onFail: "error"` | exit 0 — the
artifacts step stops failing |
| master's shape with `constraints` still present | exit 1 — reproduces
the bug |
| CI path, pnpm 11.13.0, `pnpm install --frozen-lockfile` | exit 0,
unchanged |
| `npm install` at the repo root | exit 1, `EBADDEVENGINES` — guard
intact |

`renovate-config-validator` validates the new config.

## Known remaining case

A Renovate PR that bumps `packageManager` alone leaves `devEngines`
behind and still aborts — #855 does exactly this. That is now **one**
red PR instead of the whole queue, and it is fixed by a commit syncing
both pins. `apify/crawlee` handles it the same way (apify/crawlee#4050).

## After merge

The queued Renovate PRs need a rebase to pick up a valid lockfile.
Expect #855, #846, #797 and #882 to go green on their next run.

## Separate follow-ups (not in this PR)

- **`pnpm@11.13.0` is deprecated upstream** as a broken release ("Please
install pnpm v11.13.1 or newer"); its `@pnpm/exe` build ships without a
working binary. Nothing breaks today because `devEngines` only compares
version numbers and never downloads. Bumping the pin is a prerequisite
for dropping `devEngines` entirely, which is the right long-term shape —
without `devEngines` there is no `onFail`, so pnpm defaults to
`download`, tries to install the broken 11.13.0, and hard-errors on
every install.
- **`apify/apify-cli` carries the same bug**: `constraints.pnpm:
"^11.0.0"` plus `packageManager: pnpm@11.11.0` against `devEngines`
`11.8.0`. It survives only because its `onFail` is `"warn"`, which hides
the desync.
- #884 proposes a different fix for the same symptom (browser downloads
via a `renovate.json` `env` block). That diagnosis does not hold:
Renovate's pnpm step runs `--lockfile-only`, which executes no
postinstall scripts, and repo-level `env` requires the self-hosted
`allowedEnv` allowlist (default `[]`), which the Mend-hosted app does
not grant.
- Renovate has `automerge: true` with `automergeType: "branch"`, but the
org ruleset requires 1 approving review on master — so branch automerge
can never fire and the queue piles up. Worth switching to
`automergeType: "pr"` with GitHub native auto-merge.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
@renovate
renovate Bot force-pushed the renovate/typescript-7.x branch 7 times, most recently from 03245bf to 2834b4e Compare September 15, 2026 16:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@l2ysho l2ysho Awaiting requested review from l2ysho l2ysho is a code owner
@DaveHanns DaveHanns Awaiting requested review from DaveHanns DaveHanns is a code owner

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

wontfix Issues that will not be worked on (invalid, outdated, out of scope...).

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@l2ysho @apify-service-account