-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor hydration path handling #4918
Conversation
🦋 Changeset detectedLatest commit: d3361a3 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
So close to finishing this. Looks like Deno isn't happy with importing |
This is good to go now. I've updated the PR description for the details. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Happy to sync on removing some of these post-processing patches and handling most of this in the compiler.
// TODO: Ideally the compiler could expose a `resolvePath` function so that we can | ||
// unify how we handle path in a bundler-agnostic way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, this should be possible! Happy to sync on this as a follow-up.
@@ -76,6 +85,33 @@ export default function astro(_opts: AstroPluginOptions): Plugin { | |||
); | |||
return false; | |||
}, | |||
visitObjectProperty: function (path) { | |||
// Filter out none 'client:component-path' properties |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this only needed because the compiler doesn't handle these properly yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. The compiler does handle the client:component-path
but not in the way that this PR wants it, so we're postprocessing to have the correct path instead. We should be able to remove this as well when the compiler expose a resolvePath
function so that we can resolve to the right one ourselves.
Changes
Avoid usage of
/@fs
when compiling. We still have to embrace a leading slash for Windows as the compiler is resolving paths as URLs, but this will be patched after compiling and invite-plugin-astro-postprocess
.Also undo
.jsx
stripping by compiler. We try to resolve to.tsx
early during compiling now.Ideally this patch won't be needed when I implement the next steps below.
Supersedes #4829
Next
I'll update
@astrojs/compiler
to:resolvePath
option from Astro compiler$$metadata.resolvePath
(runtimeastro/internal
api), move all to compile-time..jsx
stripping(Appreciate thoughts on the plan too!)
Testing
All existing tests should pass.
Docs
N/A. internal refactor.