Skip to content

Link the Solid 2 entry for real, and rebuild what the guard reads - #8

Merged
pathscale merged 1 commit into
masterfrom
fix/solid2-real-consumer-ci
Aug 18, 2026
Merged

Link the Solid 2 entry for real, and rebuild what the guard reads#8
pathscale merged 1 commit into
masterfrom
fix/solid2-real-consumer-ci

Conversation

@pathscale

Copy link
Copy Markdown
Owner

Follow-up to #7, addressing its review. All three points.

1. A Solid 2 consumer that actually links (the merge-blocking one)

The review is right: every job here runs the package against the installed Solid 1.9, so the 2.0 sources were only ever type-checked against the wrong major. renderer.solid-2.ts reaches omit through a cast precisely because 1.9's types do not declare it. A PR whose purpose is "make the Solid 2 consumer link" had no job that linked as a Solid 2 consumer.

fixtures/solid-2-consumer installs solid-js@2.0.0-rc.0 and @solidjs/web@2.0.0-rc.0, imports the package's solid-2 entry, and bundles it with Rspack — the linker that produced the original failure. A runtime check cannot see this class of bug: the conditional #7 removed picked the correct arm when executed and still could not be bundled.

Verified by reintroducing that conditional, which fails the new job with the message that started all of this:

ESModulesLinkingError: export 'splitProps' (imported as 'solid') was not
found in 'solid-js'

Two traps are recorded in the config, both of which produced misleading runs before the fixture worked:

  • Aliasing solid-layouts to the package root does nothing useful — an alias replaces the whole specifier, so the /solid-2 subpath export is never consulted.
  • Solid must be aliased to the fixture's copy, or the bundler walks up to packages/solid-layouts/node_modules and links @solidjs/web 2.0 against Solid 1.9, failing on a dozen unrelated exports and saying nothing about the code under test.

Scope, stated rather than implied: the fixture covers the Solid 2 runtime, not the Solid 2 compiler. It writes no JSX, so a consumer whose transform still targets 1.9 (emitting solid-js/web, a subpath 2.0 removed) is not caught here. That wants a second fixture that compiles a component.

I left the cast in renderer.solid-2.ts for now. The review suggests a plain import { omit } once a real Solid 2 job exists — correct, but it needs the package's own typecheck to run against Solid 2, which is a larger change than this PR.

2. The guard could read stale output

props-shim.test.ts built only when dist/ was missing, so an edit-then-test cycle examined the previous build: green after a change that broke it, red after a change that fixed it. It asserts emitted output, so freshness is part of the contract. Now an unconditional beforeAll.

3. The comment had the majors backwards

splitProps is the 1.9 arm that becomes invalid when linking against Solid 2, not the 2.0 arm.

Verification

  • bun test --conditions=browser — 148 pass, 0 fail
  • bunx tsc --noEmit — clean
  • The new job passes on this branch and fails when the conditional is restored

…d reads

Follow-up to #7, addressing its review.

**A Solid 2 consumer that actually links.** Every job in this repository runs
the package against the installed Solid 1.9, so the 2.0 sources were only ever
type-checked against the wrong major: `renderer.solid-2.ts` reaches `omit`
through a cast precisely because 1.9's types do not declare it. A PR whose
purpose is "make the Solid 2 consumer link" had no job that linked as a Solid 2
consumer.

`fixtures/solid-2-consumer` installs `solid-js@2.0.0-rc.0` and
`@solidjs/web@2.0.0-rc.0`, imports the package's `solid-2` entry and bundles it
with Rspack, which is the linker that produced the original failure. Verified by
reintroducing the runtime conditional #7 removed, which fails the job with the
message that started this:

    ESModulesLinkingError: export 'splitProps' (imported as 'solid') was not
    found in 'solid-js'

Two traps are recorded in the config, both of which produced misleading runs
before the fixture worked: aliasing the package root skips the `/solid-2`
subpath export entirely, and Solid must be aliased to the fixture's own copy or
the bundler links `@solidjs/web` 2.0 against the package's Solid 1.9 and fails
on a dozen unrelated exports.

The fixture covers the Solid 2 *runtime*, not the Solid 2 *compiler*: it writes
no JSX, so a consumer whose transform still targets 1.9 is not caught here.
Said in the plan rather than left to look covered.

**The guard rebuilds every run.** `props-shim.test.ts` built only when `dist/`
was missing, so an edit-then-test cycle read the previous build: green after a
change that broke it, red after a change that fixed it. It reads emitted
output, so freshness is part of what it asserts.

**One comment had the majors backwards.** `splitProps` is the 1.9 arm that
becomes invalid when linking against Solid 2, not the 2.0 arm.
@pathscale
pathscale merged commit ed8f143 into master Aug 18, 2026
5 checks passed
@pathscale
pathscale deleted the fix/solid2-real-consumer-ci branch August 18, 2026 06:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant