Refactor path resolve handling

[bluwy]

Changes

Avoid /@fs whenever possible. WIP

TODO: Investigate windows css link failures

Testing

Docs

[changeset-bot]

⚠️ No Changeset found

Latest commit: ec3f4af

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[bluwy]

Spun up my 'ol windows laptop today and I'm starting to understand why all this happens now. The Astro compiler is treating client:only and hydrated components path all as URLs, which they aren't as they are Vite/Rollup import path specifiers.

E.g. passing pathname, the transformResult.clientOnlyComponents and hydratedComponents's [<num>].resolvedPath derives from pathname. That means we're dealing with URLs instead (import specifier -> URL)

But then when building, we analyze the Rollup bundle output to link these, but the output are all raw fs paths. Comparing them against clientOnlyComponents for example becomes tricky (fs path -> URL).

I might have to re-think tomorrow on a more general fix to this. (^Jotting down notes)

[matthewp]

Thanks for doing the research to understand why the problem exists! This was the most important part of this task. The more we can wait to resolve until later the better it will be.

[bluwy]

Closing this one for now. Will open a new one with a different strategy.