René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Track the latest @rslint/core / @rstest/core: verify 0.9.0, join rstack-ecosystem-ci, un-pin E2E fixtures","articleBody":"## Problem\n\nThe extension is developed and E2E-tested against a pinned toolchain that is already behind the registry, and nothing verifies it against new releases automatically.\n\n- `@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.\n- `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.\n- 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.\n\nBefore 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.\n\n## Proposal\n\n### 1. Verify 0.9.0 now\n\n- Bump `e2e/lint/fixtures/package.json` and the `@rslint/core` devDependency to 0.9.0.\n- Change `fix: false` to `collectFixes: false` in `plugin-pool.test.ts`.\n- Run `pnpm test:e2e:lint` and fix whatever falls out.\n\n### 2. Join rstack-ecosystem-ci\n\nAdd 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.\n\n- 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`.\n- 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.\n- 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.\n\n### 3. Keep the fixtures on latest\n\n- 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.\n- 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).\n- `SUPPORT_MATRIX` in `shared/versionCheck.ts` is a floor, not a pin, and stays as is.\n","author":{"url":"https://github.com/fi3ework","@type":"Person","name":"fi3ework"},"datePublished":"2026-09-03T08:13:29Z","url":"https://github.com/rstackjs/rstack-editor/issues/40"}