-
-
Notifications
You must be signed in to change notification settings - Fork 109
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
fix: externalize transitive cjs only deps during dev ssr #289
Conversation
I was thinking that this is probably something that should be fixed purely in Vite. Vite is already including the packages in |
totally fine with fixing it in vite 👍 anyone got an idea why it's failing for codemirror-ssr though? |
I didn't look at that one yet, but codemirror is probably the hardest library I've ever encountered to get working in Vite, so I'm not terribly surprised or worried about that one. I shared with the bytemd how we got the main codemirror package working for svelte.dev |
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.
Ben made vitejs/vite#7154 which should also fix this, but I think we should also merge this one as when someone turns on prebundleSvelteLibraries
, they would hit this issue too.
if (configEnv.command === 'serve') { | ||
// during dev, we have to externalize transitive cjs only dependencies, see https://github.com/sveltejs/vite-plugin-svelte/issues/281 | ||
const optimizedTransitiveDeps = extraViteConfig.optimizeDeps?.include | ||
?.filter((x) => x.includes('>')) | ||
.map((x) => x.substring(x.lastIndexOf('>') + 1).trim()); | ||
if (optimizedTransitiveDeps?.length) { | ||
// @ts-expect-error ssr still flagge in vite | ||
if (!extraViteConfig.ssr.external) { | ||
// @ts-expect-error ssr still flagge in vite | ||
extraViteConfig.ssr.external = []; | ||
} | ||
// @ts-expect-error ssr still flagge in vite | ||
extraViteConfig.ssr.external.push( | ||
// @ts-expect-error ssr still flagge in vite | ||
...optimizedTransitiveDeps.filter((x) => !config.ssr?.noExternal?.includes(x)) | ||
); | ||
} | ||
} |
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.
I think we could move this into buildSSROptionsForSvelte()
and build the list of externals from scratch, since if prebundleSvelteLibraries
is turned off, there won't be parent > child
syntax to handle.
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.
moved it and cleaned up. not sure i follow the prebundleSvelteLibraries problem.
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.
If prebundleSvelteLibraries
is set to true
, buildOptimizeDepsForSvelte()
will early return here:
vite-plugin-svelte/packages/vite-plugin-svelte/src/utils/options.ts
Lines 244 to 252 in 681002c
if (options.experimental.prebundleSvelteLibraries) { | |
return { | |
include, | |
exclude, | |
esbuildOptions: { | |
plugins: [{ name: facadeEsbuildSveltePluginName, setup: () => {} }] | |
} | |
}; | |
} |
Skipping the below code that handles adding parent > child
to optimizeDeps.include
so there won't be any >
syntax to handle in configuring ssr.external
later on, which brings up the initial issue where nested deps (e.g. child
) weren't added to ssr.external
when it should.
To showcase this visually with the current PR's changes:
If prebundleSvelteLibraries: false
(default)
optimizeDeps.include: ["svelte-dep > cjs-dep"]
optimizeDeps.exclude: ["svelte-dep"]
ssr.noExternal: ["svelte-dep"]
ssr.external: ["cjs-dep"]
If prebundleSvelteLibraries: true
optimizeDeps.include: []
optimizeDeps.exclude: []
ssr.noExternal: ["svelte-dep"]
ssr.external: []
<- should havecjs-dep
So we have to reconstruct the ssr.external
without relying on optimizeDeps.include
😵
I wonder if we shouldn't focus on getting Vite to externalize everything by default. I took a stab at that earlier (vitejs/vite#6698), but one of the tests was failing and I didn't have time to investigate. |
is externalizing everything ok? if that was the case, why is vite doing this dance with noExternal in the first place? |
I believe it should be okay. At this point, I think the dance really isn't necessary and is just legacy that no one's taken the time to cleanup yet. Pretty much everything is already externalized and I'm not sure it would have any user visible changes. I think it's really just a single test that needs to be removed or updated. The failing test is |
I think it would be great if we can find a way to externalize everything by default. I checked the failing test and it seems like Jest is interfering it with it's own transformation. Perhaps the CJS/ESM check Vite has avoided this specific edge case, but it looks like a Jest issue to me if things are working locally without Jest. I haven't looked too deep yet. |
Ah, if Jest was doing a transform that would explain a lot because it looked like I was getting code that was different than what was on disk. Another thing I noticed is that one of the |
…rom generated list of externals
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
...new Set(svelteDeps.flatMap((dep) => Object.keys(dep.pkg.dependencies || {}))) | ||
]; | ||
// @ts-expect-error ssr still flagged in vite | ||
ssr.external = transitiveDepsOfSvelteLibs; |
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.
I wasn't suggesting to change anything here, but rather in Vite. I'm not entirely sure this is safe. I hope it is, but I can't figure out how to externalize all deps and get Vite's optimize-missing-deps
test to pass, so there might be a real issue there around deps that haven't been optimized 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.
I think it should be safe to fix this here so it works in Vite 2.8 at the meantime. Having this handled in Vite 2.9 ootb would be great though so perhaps later on we can remove this.
see #281
i'm still getting an error though when adding
bytemd
to a sveltekit projectthis is rendered in the html output of localhost:3000 after a brief flash of an unstyled editor.