Check the boundary of the major being compiled - #9
Merged
Conversation
`boundaryFor()` maps Solid 1 to `solid-layouts/application-boundary` and Solid 2
to `solid-layouts/solid-2/application-boundary`, and the library generator uses
it, so a `solid: 2` build writes the solid-2 spelling into its entry.
`validateComponent()` did not ask. It greped for the hardcoded 1.9 specifier,
which made the pairing this package generates the pairing it rejects: a correct
Solid 2 bundle failed with
<pkg>: <Name> entry has no application compiler boundary
naming a file that was exactly right. Neither specifier contains the other as
written, so `includes` cannot accidentally accept the wrong one either way round.
Thread the major from `compileApplication` through `resolveLayoutSource` to
`validateComponent` and ask `boundaryFor()`, which is what the plugin two
functions away already does. `boundaryFor(undefined)` still returns the 1.9
boundary, so nothing changes for a consumer that never sets `solid`.
Found from the consumer side: a Chuzz build on Solid 2 could not get a library
past validation with either arm. Generating for 1.9 emits `solid-js/web`
imports, a subpath Solid 2 does not export; generating for 2 failed the check
above. There was no combination that worked.
Two tests, both of which fail without the change: a solid-2 entry is accepted
under `solid: 2`, and a 1.9 entry is rejected under it. The boundary check had
no coverage at all, which is how the mismatch shipped.
pathscale
pushed a commit
to pathscale/chuzz
that referenced
this pull request
Aug 20, 2026
The boundary rewrite and its alias are two halves of one thing, and the upstream fix for both is merged (pathscale/solid-layouts#9). Name it, so whoever sees solid-layouts-oxc publish past 0.2.1 knows the pair can go together rather than guessing which of the three aliases is load-bearing. The solid-2 arm aliases are not temporary: the package ships one build per Solid major and a consumer has to pick.
pathscale
pushed a commit
to pathscale/chuzz
that referenced
this pull request
Aug 20, 2026
The boundary rewrite and its alias are two halves of one thing, and the upstream fix for both is merged (pathscale/solid-layouts#9). Name it, so whoever sees solid-layouts-oxc publish past 0.2.1 knows the pair can go together rather than guessing which of the three aliases is load-bearing. The solid-2 arm aliases are not temporary: the package ships one build per Solid major and a consumer has to pick.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
boundaryFor()maps Solid 1 tosolid-layouts/application-boundaryand Solid 2to
solid-layouts/solid-2/application-boundary, and the library generator usesit, so a
solid: 2build writes the solid-2 spelling into its entry.validateComponent()did not ask. It greped for the hardcoded 1.9 specifier,which made the pairing this package generates the pairing it rejects:
naming a file that was exactly right.
The fix
Thread the major from
compileApplicationthroughresolveLayoutSourcetovalidateComponentand askboundaryFor()— which is what the plugin twofunctions away already does.
boundaryFor(undefined)still returns the 1.9 boundary, so nothing changes for aconsumer that never sets
solid. Neither specifier contains the other aswritten, so
includescannot accidentally accept the wrong one in eitherdirection.
How it surfaced
From the consumer side, porting Chuzz's chrome to Solid 2. There was no
combination of arms that worked:
solid-js/webimports, a subpath Solid 2 does notexport, so the bundle fails earlier with
Package subpath './web' is not defined by "exports"Tests
Two, both of which fail without the change: a solid-2 entry is accepted under
solid: 2, and a 1.9 entry is rejected under it.The boundary check had no coverage at all, which is how the mismatch
shipped. 16/16 pass with the fix; reverting just the one-line condition fails
exactly the two new tests.