Nuxt Architecture

[pi0]

I thought it would be good to open this topic before we go any further. After monorepo refactors, we have new challenges that how sub-packages relate and communicate with each other. There are several concerns including where should some dependencies kept and how classes from a package will be constructed by another one. The way that we are currently going with @clarkdo is something like below. There are different kinds of packages:

Distros (nuxt,nuxt-legacy, nuxt-start)

• This packages almost has nothing inside but dependencies to @nuxt/* packages and also exporting all of their dependencies.

Utils (common, babel-preset-app)

• shared packages that may be used by one or more packages. without any context.

Core (core: nuxt + module + resolver, builder, server)

• This packages are tightly coupled together by design and should have direct access to nuxt and options. We probably can't decouple them or we should add many more complexities.

SubDeps (server: vue-renderer, builder: webpack, vue-app)

• Consumed by core packages. These may be flavored ones. Like parcel or react-app. This packages should only have a limited access to the core using specific context. So we can have better control over their behavior and also helps to support multi-threaded architecture.

Others: (cli, generator, [ui])

• DX stuff goes here.

Challenge 1: Is the way that we currently set dependencies to package.json files correct?

Challenge 2: For supporting frameworks other than vue, we need to relax vue-renderer and vue-app dependencies. Are we ready or at least on the right road?

Challenge 3: npx is broken! Because nuxt binary is provided by @nuxt/cli so we probably should add a bin folder to distro packages?

Challenge 4: How much should we keep programmatic API elegant? There are currently BW compatible aliases in the Nuxt class and it automatically constructs an instance of other core Classes. This, for example removes users ability to provide an extended version of Server (For example ExpressServer)

[galvez]

• Core (core: nuxt + module + resolver, builder, server) [...] These packages are tightly coupled together by design and should have direct access to nuxt and options. We probably can't decouple them or we should add many more complexities.

I think if these packages are tightly coupled by design, there's no need in adding a package overhead (which includes bundling and publishing) for each of them.

Perhaps we should keep core and builder together after all, that is, maintain the separation that's been done, just move files back together in the same repo?

[pi0]

@galvez The reason that we need to separate builder, is that each of them has additional dependencies. While they are tightly coupled, For nuxt-start distro we need to only core and server. Also, this is more for separation of concerns.(Mono repo) We can put every package tests inside its own and independently version them :) PS: overhead diff on node_modules is almost zero :)

[manniL]

One thing that came to my mind related to https://github.com/nuxt/nuxt.js/issues/4501. There will be hooks for different packages (say webpack/parcel/...).

We should think about providing a higher level hook that triggers the "correct" one in the package (if possible) or another way to avoid that people have to support every package manually..

[pi0]

@manniL Exactly. With context isolation, webpack should not have any direct access to Nuxt instance (It may be forked into another process). This also guarantees more stable hooks.

[atinux]

Closing it since it has been rewritten for Nuxt 3 :)