Problem
The extension is developed and E2E-tested against a pinned toolchain that is already behind the registry, and nothing verifies it against new releases automatically.
@rslint/core on npm is 0.9.0. The E2E fixture install root pins ^0.8.1 (packages/vscode/e2e/lint/fixtures/package.json) and packages/vscode/package.json declares ^0.8.0. The lint E2E slice has never run against 0.9.0.
renovate.json5 puts @rslint/** / @rstest/** / rstack in the rstack toolchain group with schedule: at any time, but ignorePaths excludes packages/vscode/e2e/** on purpose ("bumping them is a manual, E2E-verified decision"). So the fixtures never move unless someone remembers. There is also no open Renovate PR for the 0.9.0 devDependency bump, which is worth checking.
- 0.8.2 → 0.9.0 changed two wire surfaces the lint worker sits on:
CONFIG_DISCOVERY_PROTOCOL_VERSION 2 → 3 (plus a basePath field in flat-config entries) and the plugin-lint request field fix?: boolean → required collectFixes: boolean. Static reading says the worker survives both because it loads binary, config-loader and eslint-plugin host from one core root and passes the payloads through opaquely (packages/vscode/src/stacks/lint/worker/core.ts:98-153, ConfigTransactionAdapter.ts:61-149, PluginLintPool.ts:175-225). e2e/lint/suite-eslint-plugins/plugin-pool.test.ts:51-58 still builds a request with fix: false, which does not type-check against 0.9.0.
Before the standalone extensions were retired this was a non-issue: they lived in the rslint / rstest monorepos and moved with every release. Now every core release is a potential drift.
Proposal
1. Verify 0.9.0 now
- Bump
e2e/lint/fixtures/package.json and the @rslint/core devDependency to 0.9.0.
- Change
fix: false to collectFixes: false in plugin-pool.test.ts.
- Run
pnpm test:e2e:lint and fix whatever falls out.
2. Join rstack-ecosystem-ci
Add this repo as a suite in https://github.com/rstackjs/rstack-ecosystem-ci so the extension's E2E runs against each stack's main / nightly / release on the daily schedule and on demand from a rstest or rslint PR.
- rstest: add
tests/rstest/rstack-editor.ts alongside the existing rstack-cli.ts suite, running the rstest E2E slice (pnpm test:e2e:rstest) against the built @rstest/core.
- rslint: rstack-ecosystem-ci has no
rslint stack today (stacks: rsbuild, rspack, rstest, rslib, rsdoctor, rspress). Either add one (three workflows + tests/rslint/) or, as a first step, run the lint slice under an existing stack with --release. Needs a decision with the eco-ci maintainers; a counterpart issue there may be needed.
- The suite must run a real VS Code (
packages/vscode/e2e/run.mjs, VSCODE_CLI=1), so the eco-ci runner needs a display or xvfb. Check what rstack-cli.ts already does for headless runs.
3. Keep the fixtures on latest
- Decide whether the
ignorePaths exclusion for packages/vscode/e2e/** still earns its keep once eco-ci covers the "does latest still work" question. Options: remove it and let the rstack toolchain group bump fixtures too (E2E on the Renovate PR is the verification), or keep the pin and rely on eco-ci to flag drift.
- Either way, widen the devDependency ranges so
rangeStrategy: bump actually opens a PR for a new minor (^0.8.0 does not cover 0.9.0).
SUPPORT_MATRIX in shared/versionCheck.ts is a floor, not a pin, and stays as is.
Problem
The extension is developed and E2E-tested against a pinned toolchain that is already behind the registry, and nothing verifies it against new releases automatically.
@rslint/coreon npm is 0.9.0. The E2E fixture install root pins^0.8.1(packages/vscode/e2e/lint/fixtures/package.json) andpackages/vscode/package.jsondeclares^0.8.0. The lint E2E slice has never run against 0.9.0.renovate.json5puts@rslint/**/@rstest/**/rstackin therstack toolchaingroup withschedule: at any time, butignorePathsexcludespackages/vscode/e2e/**on purpose ("bumping them is a manual, E2E-verified decision"). So the fixtures never move unless someone remembers. There is also no open Renovate PR for the 0.9.0 devDependency bump, which is worth checking.CONFIG_DISCOVERY_PROTOCOL_VERSION2 → 3 (plus abasePathfield in flat-config entries) and the plugin-lint request fieldfix?: boolean→ requiredcollectFixes: boolean. Static reading says the worker survives both because it loads binary,config-loaderandeslint-pluginhost from one core root and passes the payloads through opaquely (packages/vscode/src/stacks/lint/worker/core.ts:98-153,ConfigTransactionAdapter.ts:61-149,PluginLintPool.ts:175-225).e2e/lint/suite-eslint-plugins/plugin-pool.test.ts:51-58still builds a request withfix: false, which does not type-check against 0.9.0.Before the standalone extensions were retired this was a non-issue: they lived in the rslint / rstest monorepos and moved with every release. Now every core release is a potential drift.
Proposal
1. Verify 0.9.0 now
e2e/lint/fixtures/package.jsonand the@rslint/coredevDependency to 0.9.0.fix: falsetocollectFixes: falseinplugin-pool.test.ts.pnpm test:e2e:lintand fix whatever falls out.2. Join rstack-ecosystem-ci
Add this repo as a suite in https://github.com/rstackjs/rstack-ecosystem-ci so the extension's E2E runs against each stack's
main/ nightly / release on the daily schedule and on demand from a rstest or rslint PR.tests/rstest/rstack-editor.tsalongside the existingrstack-cli.tssuite, running the rstest E2E slice (pnpm test:e2e:rstest) against the built@rstest/core.rslintstack today (stacks: rsbuild, rspack, rstest, rslib, rsdoctor, rspress). Either add one (three workflows +tests/rslint/) or, as a first step, run the lint slice under an existing stack with--release. Needs a decision with the eco-ci maintainers; a counterpart issue there may be needed.packages/vscode/e2e/run.mjs,VSCODE_CLI=1), so the eco-ci runner needs a display orxvfb. Check whatrstack-cli.tsalready does for headless runs.3. Keep the fixtures on latest
ignorePathsexclusion forpackages/vscode/e2e/**still earns its keep once eco-ci covers the "does latest still work" question. Options: remove it and let therstack toolchaingroup bump fixtures too (E2E on the Renovate PR is the verification), or keep the pin and rely on eco-ci to flag drift.rangeStrategy: bumpactually opens a PR for a new minor (^0.8.0does not cover 0.9.0).SUPPORT_MATRIXinshared/versionCheck.tsis a floor, not a pin, and stays as is.