feat: support plug-and-play, typescript runtime and native modules #8389
Conversation
nuxt-pnp
) and use jiti by default
Could the documentation suggest to use this as an alias instead? {
"dependencies": {
"nuxt": "npm:nuxt-pnp@latest"
}
} That way imports and peer dependencies would still work |
I assigned to me as well for reminding me this issue to be working on. |
This is amazing, thanks for adding this! One addition I would suggest would be to support Zero-Installs. I opened a PR for Its mostly straightforward... just version control Short version... adding the following snippet to a project's (root) "dependenciesMeta": {
"core-js": {
"built": false,
"unplugged": false
},
"ejs": {
"built": false,
"unplugged": false
},
"fsevents": {
"built": false,
"unplugged": false
},
"nan": {
"built": false,
"unplugged": false
},
"node-gyp": {
"built": false,
"unplugged": false
},
"nuxt-pnp": {
"built": false,
"unplugged": false
},
"term-size": {
"built": false,
"unplugged": false
}
} I don't know if resolving the install of those native dependencies inside |
Codecov Report
@@ Coverage Diff @@
## dev #8389 +/- ##
==========================================
- Coverage 67.62% 67.59% -0.04%
==========================================
Files 91 91
Lines 3917 3913 -4
Branches 1070 1075 +5
==========================================
- Hits 2649 2645 -4
+ Misses 1024 1022 -2
- Partials 244 246 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
TODO: windows is probably broken. Need to ovveride path
@evanrlong I tried to setup my project the same as your demo PR with zero-installs but I get errors for nuxt-pnp:
Did you come across this error? If so, how did you solve it? Edit I got it to work with |
Hi @SirWindfield. Thanks for giving it a try. If it works with |
Summary
@nuxt/cli
and@nuxt/config
)Supporting plug-and-play and yarn v2 (berry)
Berry requires every package have explicitly defining their dependencies and also passing require-path for resolving on behalf of another module. After awesome works by @paul-soporan and @arcanis to support berry (#7295) (❤️ ) we finally had to close PR since it was risking breaking changes for nuxt2 users (specially for loaders matching) and was requiring to change way of nuxt2 mono-repo packages are connected with distro dependencies and relying on
node_modules
implicit structure. (nuxt3 rewrite is already considered this)Since @evanrlong started another initiative with nuxt-berry (❤️ )
I got an idea to support a new nuxt distro(Update: solution is simplified withnuxt-pnp
fixing mono-repo issues. Technically a nuxt distro is build from source. With only difference that this special distro, squashes all packages in core (400Kbs in total) and automatically syncs dependencies. This means final install size is exactly the same but with single package (similar to nuxt3) which is fully compatible with berry without any compat mode or patches__NUXT_PATHS__
for dynamic imports in Config and CLI)Changing default require from
esm
tojiti
We started to support ESM syntax long time ago using standard-things/esm. This helped a lot adopting syntax for runtime places like
nuxt.config
andserverMiddleware
. But over the time this package started to introduce countless issues and lack of maintenance.We had to disable it for typescript-runtime and since regression with jest, we had to also auto detect jest environment and auto-disable it. At that point, I felt we really need a stable solution supporting syntax and replace esm so started developing in-house solution nuxt-contrib/jiti which is a 1MB build of babel to support both esm modules and typescript on the fly with caching and proper traces.
Even though currently it is possible to switch require engine using
createRequire: 'jiti'
from nuxt config, I think it is finally time to switch off using esm package. One plus point with this is also that we can support typescript runtime out of the box for config and middleware!What about native esm? Jiti bypasse
.mjs
requires when native support is available. Yet as it is not possible to do hot reload for modules (cache is intentionally not exposed to user level)., changing config or middleware, would require a full server reload when using native modules...Noticeable changes:
@nuxt/cli
which is used fornuxt-start
and ad-hoc moduleslodash
dependency is not bundled anymore to simplify flow@nuxt/components
/@nuxt/telemetry
which are discovered by@nuxt/config
which is also used fornuxt-start
)__NUXT_PATHS__
: Importing resolve mechanism to extend paths used for CLI@rollup/plugin-node-resolve
to avoid silent inlining of dependencies (we was doing this in past without even notice)TO...DO
createRequire
option and new features (@Atinux @debs-obrien need you help)