SSR transform doesn't respect hoisting
haikyuu opened this issue ยท 7 comments
Describe the bug
In Javascript, imports are hoisted. So the following code works
decamelize("HelloThere")
import decamelize from 'decamelized'
But when transformed in vite ssr, it produces the following
__vite_ssr_import_0__.default("HelloThere");
const __vite_ssr_import_0__ = await __vite_ssr_import__("decamelize");
Which obviously doesn't work and produces the following error
Cannot access '__vite_ssr_import_0__' before initialization
Originally opened in vitest-dev/vitest#2138 but it's a Vite issue actually.
I believe this is a bug for two reasons:
- Valid JavaScript code doesn't work when using Vite
- inconsistency between dev and production modes of Vite. (this works when doing a production build, imports are moved to the top of the file)
Reproduction
https://stackblitz.com/edit/vitejs-vite-xhfybw?file=vite.config.js,server.js,entry.js&terminal=dev
Steps to reproduce
Run node server.js
and you will see the error.
It's worth noting that the production SSR build actually works. So this is an inconstintency as well
System Info
System:
OS: macOS 12.4
CPU: (10) arm64 Apple M1 Max
Memory: 88.67 MB / 32.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.17.0 - /usr/local/bin/node
Yarn: 1.22.17 - /usr/local/bin/yarn
npm: 8.15.0 - /usr/local/bin/npm
Browsers:
Chrome: 106.0.5249.103
Chrome Canary: 108.0.5355.0
Safari: 15.5
Safari Technology Preview: 16.4
npmPackages:
vite: ^3.1.0 => 3.1.0
Used Package Manager
npm
Logs
Error: Cannot access 'vite_ssr_import_0' before initialization
at async ESMLoader.import (https://vitejs-vite-xhfybw.w.staticblitz.com/blitz.ea2f6b48b77806aba8e6fe3b6311530cc7674f64.js:6:1209286)
at async i.loadESM (https://vitejs-vite-xhfybw.w.staticblitz.com/blitz.ea2f6b48b77806aba8e6fe3b6311530cc7674f64.js:6:246623)
at async handleMainPromise (https://vitejs-vite-xhfybw.w.staticblitz.com/blitz.ea2f6b48b77806aba8e6fe3b6311530cc7674f64.js:6:989295)
Validations
- Follow our Code of Conduct
- Read the Contributing Guidelines.
- Read the docs.
- Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
- Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
- Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
- The provided reproduction is a minimal reproducible example of the bug.
Maybe s.prepend
should be used here, hoist the import statement to the top? ๐ค
vite/packages/vite/src/node/ssr/ssrTransform.ts
Lines 98 to 100 in 29292af
Yeah I think we could try that. I don't see any caveats at a glance. Having the import order preserved would be good too for easier debugging.
This issue is blocking my team's ability to use Vitest with Chakra-ui in our monorepo. Are there any updates?
Hello @haikyuu. We like your proposal/feedback and would appreciate a contribution via a Pull Request by you or another community member. We thank you in advance for your contribution and are looking forward to reviewing it!
Linked issue in the Vitest repo:
Hello dear Vite-Contributors,
our team also hopes that you find time to fix this. Anyway, we apprechiate your support very much! ๐๐
In the meantime, some clumsy workaround to make Vitest usage in pipelines possible until this issue is fixed can be found here: in a comment on the linked Vitest issue 1527 at the end of the comment.
Happy hacking ๐
This issue is blocking my team's ability to use Vitest with Chakra-ui in our monorepo. Are there any updates?
Having issues here as well trying to use vitest to test some components that use chakra-ui