-
-
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
Load configs with Vite when loading with Proload fails #4112
Conversation
🦋 Changeset detectedLatest commit: 7028fca The changes in this PR will be included in the next version bump. This PR includes changesets to release 13 packages
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 |
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.
Suggestion on the config server, but I'm promerge on this one!
@@ -49,7 +49,7 @@ export default function mdx(mdxOptions: MdxOptions = {}): AstroIntegration { | |||
// Workarounds tried: | |||
// - "import * as remarkShikiTwoslash" | |||
// - "import { default as remarkShikiTwoslash }" | |||
(remarkShikiTwoslash as any).default, | |||
(remarkShikiTwoslash as any).default ?? remarkShikiTwoslash, |
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.
Good thinking here. Wonder if proload was somehow messing with the .default
here...
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.
That's not why proload was failing. But this is needed to be compatible with loading in Vite.
|
||
return config as TryLoadConfigResult; | ||
} catch(e) { | ||
if (e instanceof ProloadError && flags.config) { |
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.
does this mean that --config
won't work with .ts
config files? Could this be moved to further down to be a final catchall, OR earlier in the function with a fs.stat
call to check that the file exists before running proload or vite?
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.
No, this condition hits when the user passes a --config
but that file doesn't exist. If the file does exist and is a .ts
file it will either a) have worked through proload or b) caught here, but the instanceof
check will fail and it will load through the subsequent Vite mechanism.
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.
LGTM!
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.
LGTM! Was there prior art to this strategy? It's clever but does it also mean that every dependency of your config file needs to run in Vite's SSR mode? Not sure how worried to be about that risk, but at the very least thankful that deps are all marked as external in vite 3.
Dependencies should be auto-external in Vite 3, so I would only assume that code from the local project needs to run in Vite's SSR mode. That's why I did it as a fallback because most of the time (I guess if you're not using mdx) it will load through the normal proload flow. I think maybe the ideal fix here would be to skip both proload and Vite loading and just run the source through esbuild to remove types and then |
Changes
vite.createServer().ssrLoadModule
to load the config, rather than using preloads plugins.@astrojs/mdx
withastro.config.ts
fails to start #4078Testing
Docs
N/A