Skip to content
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

feat: ssr build using optimized deps #8403

Merged
merged 1 commit into from
May 31, 2022

Conversation

patak-dev
Copy link
Member

Description

Follow up to:

This PR removes the need for @rollup/plugin-commonjs for SSR builds, enabling dep optimization using esbuild by default for them.

After this PR, if the user doesn't use optimizeDeps.disabled: 'build' or optimizeDeps.devScan: true then Vite isn't using plugin-commonjs or the esbuild scanner. In the same way we are doing with terser, we could decide in Vite v3 to avoid @rollup/plugin-commonjs as a dependency and ask users to add it to the project themselves if they need it. It isn't a big dep though, so probably not worthy.

There is a new deps cache for SSR. We could discuss if the build cache could be reused, but given that most deps will be externalized, I think a separate cache wouldn't affect performance. It will allow users to avoid busting the cache if there is a conditional change for the config depending on if we are building for SSR.
Given that we have more caches now, this PRs renames them to be more future proof:

  • deps
  • deps_build
  • deps_build_ssr

And the prev processingDeps are now the same as above but with a _temp suffix. About using a flat structure instead of deps/build, we discussed in a previous PR with Anthony and Blu that this structure is easier to work with.

I thought about renaming deps to deps_dev, but I left it as deps because it is shorter and this dir is seen in the browser network tab.

@benmccann @brillout I would need some help with testing and validating here. Tests are passing on Vite's side, but maybe we should expand them.


What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

@patak-dev patak-dev added feat: ssr breaking change p3-significant High priority enhancement (priority) labels May 30, 2022
@patak-dev patak-dev added this to the 3.0 milestone May 30, 2022
@patak-dev
Copy link
Member Author

Merging as this could be considered part of the work done in:

Let's release an alpha so we help the ecosystem test these changes. If you see an issue here, let's discuss it further PRs

@patak-dev patak-dev merged commit 6a5a5b5 into main May 31, 2022
@patak-dev patak-dev deleted the feat/remove-plugin-commonjs-for-ssr branch May 31, 2022 08:45
@brillout
Copy link
Contributor

brillout commented Jun 1, 2022

I never fully understood how the externalization algorithm worked so I'm not sure I'd be much of a help here.

If CJS will eventually be deprecated, I wonder whether it's "worth it" to test it.

I'd even argue that having a broken CJS support would be a good thing :-). On a more serious note: #8432.

@patak-dev
Copy link
Member Author

patak-dev commented Jun 1, 2022

@brillout what is going to be helpful is to make vite-plugin-ssr CI pass with the alphas, with the new defaults that don't use the scanner and plugin-commonjs. If there are breaking changes, you can create a vite-3 branch as SvelteKit did and temporarily update vite-ecosystem-ci to use it so we can get everyone green again.

See https://github.com/vitejs/vite-ecosystem-ci/pull/77/files

@brillout
Copy link
Contributor

brillout commented Jun 1, 2022

@patak-dev Will do.

@patak-dev patak-dev mentioned this pull request Jul 4, 2022
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change feat: ssr p3-significant High priority enhancement (priority)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants