Skip to content

Track the latest @rslint/core / @rstest/core: verify 0.9.0, join rstack-ecosystem-ci, un-pin E2E fixtures #40

Description

@fi3ework

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions