Nuxt 3 support

[mklueh]

Now that Nuxt 3 is officially out of beta, is there any plan to support it with nx-plus?

[colinscz]

Hi @ZachJW34

Is there a preference from your side how the nuxt3 support should be handled in the existing plugin/repo structure?

As of now Nuxt2 is still used widely so I think a separate nuxt3 plugin within the repository wouldn't be a bad idea. As Nuxt2 would still need to be supported for some time.

Is there any plan from your side to start the work on this or can a proposal be provided? 😃

[ZachJW34]

I'd want to handle it the same way Nx handles upgrades e.g. once they upgrade to the latest version they drop support for the older version. Users can still use the older version but they'd be stuck on an older version of Nx. As long as there is a good path for migrating to the new version (via migrations), then that's what I'd recommend. I don't have too many downloads of @nx-plus/nuxt so even if there isn't something we can do with migrations, a doc explaining the upgrade path would be sufficient.

As for the implementation, I've always generated a new nuxt app and do some comparisons between what I scaffold and what the new scaffold looks like and bring those into alignment. Hopefully, most of the generator/executor code can be reused but I imagine there will be significant changes required to get it working.

Working on this would look like:

• Update the schematic to generate what a npx nuxi init nuxt-app would give you.
• Update the build/serve executor to get it serving locally with the new nuxt3 API
• Update the schematic to get Jest unit testing working (might be cool to switch to vitest)
• Update the schematic to verify eslint is working
• Update unit tests
• Update e2e tests
• (Optional): Create a migration script

Some tools that help when developing locally:

• yarn create-playground creates a fresh nx projects inside tmp/nx-playground-proj and links the npm packages
• yarn update-playground updates the linked npm packages

Decent amount of work here, but Nuxt3 support would be awesome and I'd appreciate a contribution and can help out along the way. I have vue-cli@5 I need to get around to as well, but I plan on eventually getting around to both. Nuxt3 is still in RC, so I don't expect to officially support it until it lands stable but I'm sure that's soon and I don't expect any drastic changes by that time so getting a jump-start on it would be good.

[colinscz]

Ok @ZachJW34 I can start to work on a PR to make this happen. Probably need a bit of time to get familiar with the plugin setup but somehow I will manage. 😄

I will follow your guide as close as possible. As soon as I have a first draft I open a WIP PR where the progress could be inspected.

As I plan to use Nuxt3 inside a Nx monorepo along other applications it's also something I would love to get working for my own benefit. The team has just released RC 5 and I am confident that this is one of the last RCs before the major release sees the light of day.😃

@danielroe I see you noticed this conversation. I'd like to tag you or somebody else you suggest from the Nuxt core team to follow along in case of issues on that PR, if that is ok? I think that could be helpful in case we run into some issues.

If a migration script makes sense or is feasible I tackle that last since the migration guide to Nuxt3 is also still being worked on.

[ZachJW34]

@cnschwarz Awesome glad you're working on it! I can help out along the way

[danielroe]

... and very happy to be pinged if I can help too. Discord is best for quick back and forth.

[jamesray]

Glad this is being worked, hopefully it'll pick back up now that Nuxt 3 is on RC12 🍾

[mklueh]

I'm currently setting up Nuxt 3 apps with NX without the plugin and I'm so far not missing anything and its not a blocker, although it involves some manual configuration of the project.json file and modification of the workspace.json. But I'm not using any e2e tests etc and my setup is pretty simple.

One thing I'm not sure about is how to deal with the .tsconfig that is generated by Nuxt and located in the .nuxt directory. How would you extend from the root tsconfig but still use those configs each Nuxt application generates?

[colinscz]

@mklueh the thing with the .tsconfig is something I found during my past work on the pull request and I haven't yet mentioned it as a todo - it's now added to the PR as an open point, thanks for pointing this out.

@danielroe maybe you can let me know from your side how this would best fit in, maybe there is a way to extract the nuxt tsconfig in some way and put it inside the generated tsconfig for the generated project instead of extending from it. I am open to suggestions on the PR.

[mklueh]

@colinscz glad to hear. Is there any recommended way?

I had moved the nuxt tsconfig into the root of the project. But the problem is the paths

      "vue-demi": [
        "../../node_modules/nuxt/dist/app/compat/vue-demi"
      ],
      "#head": [
        "../../node_modules/nuxt/dist/head/runtime"
      ],
      "#head/*": [
        "../../node_modules/nuxt/dist/head/runtime/*"
      ],

Depending on what module it uses and in what directory hierarchy it sits, extending from it will use the wrong paths. Some packages might be 3 directories deep from root, others only 2.

Maybe the best way would be to pass a top level .tsconfig path into a Nuxt config and let Nuxi extend from it? Or better: for some reason, Nuxt seems to already know how far away the application is from root. Why can't it automatically look for a .tsconfig in the root and extend from it if it's available?

[danielroe]

Can you explain a bit about how/why Nuxt needs to extend from another tsconfig? What values in that tsconfig are important for the nuxt project?

[mklueh]

@danielroe I have a very limited understanding so far of how things work, and all I'm trying to do for weeks now is setting up a working NX monorepo with Nuxt apps and a shared UI library.

However, here is an official nx example project where you can see that apps and libraries all point to the root tsconfig: https://github.com/nrwl/nx-examples

It's documentation states: "Regardless whether you use JavaScript or TypeScript, you will have a tsconfig.base.json file at the root of the workspace. It's not used to build the applications and libraries in the workspace. It's only used to improve the editor experience." https://nx.dev/recipes/other/js-and-ts#javascript-and-typescript

I guess if this is not done, WebStorm can't find components across modules. However, I've also read somwhere that .eslintrc.json files are responsible for that.

Maybe there are other implications - consistency-wise it would make sense to have identical configurations among all of the applications and modules within a monorepo.

[colinscz]

@danielroe I searched through the nx docs and found these references that hopefully help to put the puzzle together:

https://nx.dev/more-concepts/applications-and-libraries#applications-and-libraries Nx automatically creates TypeScript path mappings in the tsconfig.base.json file, such that they can be easily consumed by other apps or libs

https://nx.dev/more-concepts/customizing-inputs#global-settings

https://nx.dev/more-concepts/folder-structure#integrated-repo-folder-structure /tsconfig.base.json sets up the global TypeScript settings and creates aliases for each library to aid when creating TS/JS imports.

I see two directions:

1. Nuxt's current tsConfig settings like the complierOptions can be somehow placed within a newly generated nuxt project within NX and we could still extend from the regular tsconfig.base.json. If these configurations change upon a Nuxt upgrade, we could update the tsconfig or leave it up to the user for an existing project and only care about freshly generated projects.
2. There might be an option that a Nuxt project can directly extend from the nuxt-ts-config but this would break with the nx workspace concept, unless we have an option to respect this setup through an additional configuration. Currently I don't see a way on how to achieve this as it would probably break the workspace.

What do you think? Do you see any other tsconfig parts that I missed or that should be inherited? My reference: https://github.com/nuxt/framework/blob/main/tsconfig.json

[anlek]

Any updates on this?

[colinscz]

Update for the ones watching: Currently blocked due to some issues with the implementation - for more details please have a look at the corresponding PR.

I requested involvement/review from the library authors @ZachJW34 @BuckyMaler

Once they find time we can resume the work. If you are eager to get it running asap then feel free to have a look at my draft PR - help is always welcome 👍🏽 #269

[avxkim]

@ZachJW34 is this project abandoned?

[vitebo]

with typescript in version 5 it is possible to extend more than one tsconfig, getting like this

{
  "extends": [
    "../../tsconfig.base.json",
    "./.nuxt/tsconfig.json"
  ]
}

maybe this helps

Refs: https://github.com/microsoft/TypeScript/issues/42386#issuecomment-1550612552

[avxkim]

@vitebo have you tried yourself it in nuxt 3?

[vitebo]

@avxkim I hadn't tested it, but I ended up going with a monorepo based on packages using the Nuxt layers that best served my needs.

But I created a repository here to try to validate this idea, and unfortunately, it didn't work.

The "multiple extends" even work; the problem is that the definition of paths in tsconfig.base.json overwrites the paths of Nuxt. It is recommended that these paths be placed in alias in nuxt.config.ts.

Refs: https://nuxt.com/docs/guide/directory-structure/tsconfig#typescript-configuration-file

[avxkim]

@vitebo have you switched to pnpm monorepos?

[vitebo]

for now we are still using npm but we have plans to switch to pnpm