Improved Directory Structure about nuxt HOT 66 CLOSED

I'm also expecting app router like next 14 and route group. now if we need auth routes in auth folder then route become

/auth/login
/auth/register

it will be good if

pages/
    (auth)/
        Login.vue
        Register.vue

route now should be

/login
/register

Only index.vue accessible in router

pages/
    (auth)/
        Login/
            index.vue
            style.css

from nuxt.

@Shooteger Please don't assume we're just making a change because 'some few individuals prefer it one way.' The change aims to improve:

1. performance - having a srcDir in the root of your repo causes issues with .git/ and node_modules/ folders being scanned/included by FS watchers which can significantly delay startup on non-Mac OSes.
2. IDE type-safety - server/ and the rest of your app are running in two entirely different contexts with different global imports available, and making sure server/ isn't inside the same folder as the rest of your app is a big first step to ensuring you get good auto-completes in your IDE.

Having said that, it's already implemented in the nightly release, and I think you won't mind it. It will detect your usage and seamlessly fall back to the current folder structure, if you don't adopt it.

If you want to do so explicitly it's configurable with as little as this:

export default defineNuxtConfig({
  srcDir: '.',
  dir: {
    app: 'app'
  }
})

Finally, I would note that assuming we are 'wasting everyone's time' is really quite unkind. Please consider how you talk to people online.

from nuxt.

@danielroe How about nuxt ? :D

Reposting my thoughts from the initial discussion :

I really like the fact that we now have server/routes, and plugin and modules are now clearly separated.

I think that if we are changing the structure, we should consider more changes and bring in more benefits.

• app is a generic name
• There's now an additional level of nesting
• app/router.options.ts feels out of place
• content is not a part of nuxt/core, which other modules should be considered ?
• difference between utils and composables ?
• why not get rid of both utils and use composables everywhere?
• what about app.config.ts ? Is it deprecated ?
• why main.vue and not index.vue ?
• where would tests go ? That should be part of the directory structure imo

Instead of app and server, I suggest nuxt and nitro.
This makes things clearer imo :

• Explicitness of Nuxt and Nitro as TLD (nuxt/layouts, nuxt/plugins, nitro/plugins all read very nicely)
• Align standalone nitro and nuxt directory structure
• Bootstrap the new .config directory structure proposal

Here's what I'm thinking :

.output/
.build/
node_modules/
nuxt/
 assets/
 components/
 content/ #this should be next to pages
 composables/
 layouts/
 middleware/ 
 pages/
 plugins/
 tests/ # component tests
 index.vue # could be main.vue
nitro/
 public/ # this is more consistent with how nitro works
 api/
 middleware
 routes/
 plugins/
 tests/ # server only tests can go here.
 composables/ # align with vue conventions
 utils/ # we could keep this but I've personally always hated it 
layers/ # layers and modules could be nested under something like extends/
modules/
.config/ # To align with Pooya .config proposal
 nuxt.ts 
 app.ts  # could be moved to runtime.config.public
 nuxt-router.ts
tests/ # global/integration/e2e tests can go here
nuxt.config.ts # we could support this as well

Minimal starter

nuxt/
  index.vue
nitro/
  public/
    favicon.ico/
.config/
    nuxt.ts

from nuxt.

can we include a src directory?

.
├── ./public
├── ./src/
│   ├── ./app
│   ├── ./middleware
│   └── ./server
└── nuxt.config.js

from nuxt.

@dargmuesli It's already implemented!

from nuxt.

Not sure for content/ as I found it similar to public/ and the data is not bundled.

It also allows having a minimal usage when used with a Nuxt Layer:

content/
  index.md
public/
  favicon.ico
nuxt.config.ts <-- Using extends: 'my-docs-theme'

from nuxt.

I believe we can easily detect the old format and have a way to upgrade to the new one by running either nuxt dev or with a nuxi upgrade command.

from nuxt.

I hope my thought process will help making slightly less opinionated decision here.

The challenge here is about naming things, like with variables in the code. So the goal is to make it natural/the most obvious name for others, right? In the context of directory structure it seems that one decision is already made: using server for the code than runs on server. So the most natural opposite term based on dichotomy will be client. Any other term will leave much room for interpretation and at least for some people will create confusion. So ultimately the code is divided by where it runs (which makes it a bit more complex in case of SSR).

While client/server dichotomy is very fundamental in IT, I think there is a better one. Since most devs have clear roles as frontend or backend developer, I believe using this dichotomy will be even more obvious so in this case the code is divided by responsibility/developer's roles (which is also obvious for full-stack dev).

Now, we could test three cases (app/server, client/server and frontend/backend) with a real life scenario: I have UserSchema written in Zod which will be run in the server and in the browser, so where should I put this?

1. app/server - without analyzing what is the role of each directory I think it sounds more natural to say that UserSchema is part of the app. Server importing from app does not sound that bad, right?
2. client/server - I could choose server as it the source (where user is created) or I might go with a /shared folder from which both will import.
3. frontend/backend - as above but I think that there will be more preference over a shared folder.

I believe that above makes it quite clear how personal preferences might impact it, I really would like to make it as easy as possible to understand by the most junior developers while hoping it might support better decision making and making collaboration between BE/FE devs easier.

Ultimately, as a product guy, I think that checking with community using a poll with similar test case might generate some engagement and feeling of having impact on the future of the tool we all love.

from nuxt.

Hey all 👋🏻

Thanks a lot for all your input and suggestions! I wanted to comment and share my personal opinion with regard to some of these here ☺️

@eunjae-lee

In my mind, Nuxt app is a combination of vue's frontend and the backend. So seeing app and server separately makes me feel like this server is something outside this Nuxt app.

I'd say you could simply take the server folder and run it a standalone Nitro app, yes.
But of course, for SSR'ing your Nuxt app, Nitro is "needed", same for running Nuxt plugins on the server side. But this code is all in the app folder anyway. I tried explaining that a bit ago here.

But I like the server being separate as it's really server-only thing.

This exactly!

On the other hand, app folder contains lots of stuff that is actually shared across frontend and backend.
I've moved plugins out on the same level as modules

I think moving plugins up isn't the way to go, as "Nuxt plugins" should stay within the Nuxt app while Nitro plugins belong in the server folder as these are two fundamentally different plugin types. ☺️

could you probably give us more insights on what kind of separation for the app level you meant, and what kind of problems we're trying to solve here?

I am not @Atinux but separating the Nuxt app from the server helps understanding the "boundaries" between your "Nuxt/Vue" part (even if it might be SSR'ed) and the "server" part a bit more. Lots of people try using pinia or Vue composables in /server, which could be less tempting with the new structure from my POV.

@wajeht app will be treated as srcDir "internally".

@therealokoro client might suggest that the application is client-only, but as Nuxt is capable of SSR and the content in that folder will be SSR'ed, it could trip off people IMO.

@Hebilicious

How about nuxt ?

Would that mean that Nuxt can "exist" without nitro or that Nuxt "does not include Nitro"? 🤔

* `app/router.options.ts` feels out of place

Where else would you put it? 🤔

* difference between `utils` and `composables` ?
* why not get rid of both utils and use `composables` everywhere?

The difference is a big one semantically (e.g. explained in this video) - happy to see clear separation there.

* why `main.vue` and not `index.vue` ?

The name of the "App.vue" replacement is still to be discussed. I personally think App.vue would still suit the best as index.vue could be confusing (as it is not file-system based routing) and hard to find (when using fs-based routing you have so many index.vue)

* where would `tests` go ? That should be part of the directory structure imo

IMO:

• Unit tests folder - nowhere, tests close to your components, ___tests__ if necessary
• E2E-tests top-level.

Instead of app and server, I suggest nuxt and nitro ? This makes things clearer imo :

• The more I think about it, the more I begin to like that! 🤔 Only the first question (Would that mean that Nuxt can "exist" without nitro or that Nuxt "does not include Nitro"? ) isn't resolved with that.

from nuxt.

Instead of app and server, I suggest nuxt and nitro?

Love it! That's exactly the mental model I push internally in the company I work for.

I do think it's simpler to understand than the app/server structure where you have to mentally map the app directory to the Nuxt context, and the server directory to the Nitro context. It becomes trivial to understand that the nuxt/plugins directory can only contain Nuxt plugins and that the nitro/plugins can only contain Nitro plugins for example.

To me, reflecting the Nuxt and Nitro contexts onto the directory structure makes the whole thing simpler to understand and also to communicate.

from nuxt.

Before I read this issue fully my gut reaction was it should be app because that is what first jumped into my mind, and now after reading the full issue I think app is still the winner because of ambiguity of the word.

Words that try to be more specific will fall short of encapsulating the full breadth of what is/can be done in the app directory. The narrowest alternative I can come up with is vue (this is where the vue part of the app lives after all) — but even that falls short of describing the full breadth.

I‘ll cast my vote towards app.

from nuxt.

Shouldn't we also move the content/ dir into the app/ dir? I think that way, it would align better with the usage of each dir.

from nuxt.

What I like about Nuxt is that it blurs the lines of a traditional frontend/backend, client/server setup. And with server side pre rendering the frontend is not necessarily running on the clients side. So in that line naming it client/server might make you think in that more traditional way. Something like interface/api might work since it doesn't imply where it is run just what it is.

I am on the same page. I do not believe there is any ideal solution here. But with impact of Nuxt on the dev world, I am pretty sure that based on the naming potential confilicts between team members might be minimalized. There was a saying in one company I worked with that it is easier to offend someone by talking about one's technology than one's mother. And that is the perspective I try to bring. Making the structure as easy as it can be is really hard here, actually this seems to be the hardest decision from all in v4 backlog. It seems so trivial that almost everyone might be an expert here.

from nuxt.

This is my current approach

As said by someone above, I feel app is more like an overall name, more like an alias to the word project.
An app could have the client and server side. It makes more science to me.

Now the question would be.... "Where should the modules folder go?"
In a case were a user writes a quick module and needs the module folder, where should the module folder go?

In my opinion, since a module can contain both server and client code, then it should be on same level as the client and server folder

At the end of the day I also believe having all of these customizable via the config file as it is now will just be the best solution.

from nuxt.

To be honest, my colleagues and many friends around the globe who use Nuxt are totally fine with the current Nuxt folder structure.

Just ask yourself, what would really be the benefit implementing a possible breaking change or more "rules" which some would not follow.

The current system, where you do NOT have dozens of sub-folders is great! I know instantly where everything is. Components is clear, layers, server dir with a few sub-dirs... What would be a not a potential but a REAL benefit changing this with v4 soon?

Please correct if I am wrong, but I just don't see any really improvement by doing that, rather than more downsides and slightly bigger hurdle for new programmers getting used to this.

I would suggest focus on stability, performance and real new features, not wasting everyone's time in learning a new folder structure, while it has no overall benefits, rather than some few individual prefer it one way.

from nuxt.

Lots of love, peace, health, and success to the amazing Nuxt team. 💚🔥👏🎉

from nuxt.

We're also discussing ideas like ui, web, frontend, vue, but still feeling that app is frontrunner here. Other ideas welcome.

I agree that app sounds like the best one. Unless we split our app into multiple layers, in which case it would be strange to call each layer an app (if doing DDD) because in that case a layer is more of a module than an app.

from nuxt.

app/ certainly has my vote. Love this proposal, I never found an issue with the structure until I saw this post though honestly.

from nuxt.

I totally agree with the directory separation, but not with the suggested app contents.

One of my sites is way more separated, but see things such as middleware as base rather than app:

However, I think the implication that layers should ship as standard is a great idea.

So as folks just can't seem to align on what is base and what is app (or something else) maybe just let folks decide for themselves:

app/
  main.vue
base/
  public/
    favicon.ico
nuxt.config.ts

from nuxt.

How about nuxt ? :D

Don't we have a .nuxt folder already? Wouldn't it cause confusion?

from nuxt.

@martinszeltins — a quick opinion on pages vs views: I think everything in the current pages folder is intended to be a routable target? Whereas "views" could be seen to include partials (and potentially other non-routable elements), especially if coming from other frameworks like Ruby on Rails where the views folder contains both routable targets and partials.

FWIW, I've made peace with the concept of "pages" in web apps, as I think it best describes what it is: a routable target, and also works well for SSR scenarios (where a request comes in for a path and a particular view is rendered, which can contain other views [aka componentsin Vue/Nuxt]).

from nuxt.

@Lootjs yes, server/plugins will not be removed 👍🏻 Edited the original post ☺️

from nuxt.

We're also discussing ideas like ui, web, frontend, vue, but still feeling that app is frontrunner here. Other ideas welcome.

from nuxt.

@Gonzalo-Bruna I already told this to someone on twitter (answering Daniel, who linked this thread), sure, the server is part of the app on a dev's perspective. But, on the user's POV the app is what they see and use directly, aka the front.

Think of this as a mobile app: the user downloads an app from his store, very often what he downloaded was only the front.

from nuxt.

@danielroe I think you mentioned the wrong person 😅

Also, I wasn't aware of the performance issues on non-Mac OSes. Does it include Linux too? Or is Windows the only one suffering from it?

from nuxt.

@danielroe
Thank you for the clear statement and comment. There was absolutely no offence given. I just thought about if you would "force" the new structure it would waste time learning new (what it would with many, many people).

But as you just stated now, it is optional with automatic fallback and therefore not the case. Thank you very much and peace 😎

from nuxt.

I would say in ~/utils if they are used both in server and app

from nuxt.

Discussed in #20251

Originally posted by Atinux April 13, 2023 Nuxt 3 is now a fullstack framework thanks to Nitro with the ability to have auto-imported modules and layers, I believe it's time to rethink the directory structure to give more separation for the "app" level.

This is the proposal I am thinking of:

.output/
.nuxt/
app/
  assets/
  components/
  composables/
  layouts/
  middleware/
  pages/
  plugins/
  utils/
  main.vue
  router.options.ts
content/
layers/
modules/
node_modules/
public/
server/
  api/
  middleware
  routes/
  utils/
nuxt.config.ts

Do you see any downside of this approach?

The minimal starter would then be:

app/
  main.vue
public/
  favicon.ico
nuxt.config.ts
```</div>

I guess also a tsconfig.json is required for the minimal starter

from nuxt.

sigh of relief

from nuxt.

src of course!

from nuxt.

Wonderful points by @manniL and others.

Well I don't know if this will be of any help, but here's what ChatGPT has to say 😅

Link to the chat => https://chat.openai.com/share/50d4f3aa-5f63-4a1b-99ae-13d3a69de1ce

from nuxt.

Here's my take:

1. Initially, I thought about src, as I usually put everything in a src folder and create an alias in nuxt.config This is because there are numerous items at the root level. However, I wouldn't recommend src since the contents of plugins, server, and more are also part of our application's source. (I'm unsure about assets, though.)
2. Many suggest app, which I agree with, particularly as it has become a de facto of some sorts.
3. I also appreciate the idea of a client folder existing alongside the server folder.

That said, I believe app would be a more appealing default option.

The only drawback here is app.vue would be in the app directory, resulting in app/app.vue, which seems to be the reason behind renaming that to main.vue

from nuxt.

The "/app" directory name seems the most 'common / people are used to it', but the server directory is also part of the app, so it might be confusing at first.

What about the "/UI" directory? In the end, regardless of whether some components will be client- or server-rendered, everything in this directory will be connected to the UI and will be a part of it.

from nuxt.

What about new ‘routes’ as alternative to ‘pages’, or maybe other option beside it, I really love remix v2 routes directory, I prefer it for big projects to work as vertical slice architecture

I wish see it soon in nuxt

from nuxt.

How about nuxt ? :D

Minimal starter

nuxt/
  index.vue
nitro/
  public/
    favicon.ico/
.config/
    nuxt.ts

@Hebilicious I liked this idea at first but, imho, it brings the same problems as calling them server/client: the "nuxt" part of your code may need nitro. I still think that "nitro" would be a good name for the server part, but I'm not sure it brings any benefits over the current name.

from nuxt.

For now, Nuxt and Nitro are tightly coupled, but I'd like to imagine a (distant) future where it would be possible to configure this, and use a different server engine (Laravel, Django, Elysia ...) officially through a configuration option. Since we support multiple bundlers, we could attempt multiple servers. If that ever happens maybe both Nitro and the other server would be present, so having this directory structure would remain clear.

@Hebilicious Love this train of thought. My agency's stack is laravel + vue, but as the frontend developer, I would love the DX improvements that nuxt brings.

from nuxt.

I personally stay away from "client/server" these days and especially not "front-end" / "backend", as these terms are getting more and more vague/ somewhat relative.

I'm in the nuxt/nitro proposal camp if anything, although, I don't really see the value upside vs what we already have, I kinda like the flat structure, mostly to avoid having to think about exactly this discussion lol this notion feels a little like fixing something that isn't broken

A default top level base folder might not be a bad idea though for "app" or "src". Mostly just for aesthetics though, so that root repo directories don't look overwhelming/messy.

from nuxt.

On the side note, this rfc would be equal to just changing the default srcDir and serverDir, so that people can easily revert to the original flat structure right?

from nuxt.

Well, most improvement could come from a much more considerate integration system for i18n. Currently I have a couple of projects and I know a lot of people in the industry having to do some wonky stuff to get the basic routing up and running with the translations. The ability to have some better page directory override that could "talk" a little bit closer with i18n would be great. Like picking up meta tags and also the ability of adding translated aliases or custom regexs to the page directory.

from nuxt.

I think it's change and not a lot of change

I think Middleware is just more proper English.

from nuxt.

@mahmoudyusof exactly

from nuxt.

Love it! 💚

What will be the best approach to share common utils that can be used in /server and /app e.g some string manipulation utilities.
Put’em in /layers?

from nuxt.

Love the new proposal!

Would you need to follow this structure to upgrade from v3 to v4?

Laravel recently changed its boilerplate folder structure. Although the new version works with the previous folder structure, users fear that if they don't adapt to the new structure, future code might break because they have things in the wrong place.

from nuxt.

I would say in ~/utils if they are used both in server and app

Is this also the folder to place data types? For example data structures stored in cookies or used in api routes that are used by both server and client? I know there is support for the '~/types' folder but it isn't mentioned anywhere.

from nuxt.

Can we keep server/plugins/ for server plugins? 👀

from nuxt.

1. app/server - without analyzing what is the role of each directory I think it sounds more natural to say that UserSchema is part of the app. Server importing from app does not sound that bad, right?
2. client/server - I could choose server as it the source (where user is created) or I might go with a /shared folder from which both will import.
3. frontend/backend - as above but I think that there will be more preference over a shared folder.

What I like about Nuxt is that it blurs the lines of a traditional frontend/backend, client/server setup. And with server side pre rendering the frontend is not necessarily running on the clients side. So in that line naming it client/server might make you think in that more traditional way. Something like interface/api might work since it doesn't imply where it is run just what it is.

from nuxt.

In my mind, Nuxt app is a combination of vue's frontend and the backend. So seeing app and server separately makes me feel like this server is something outside this Nuxt app. But I like the server being separate as it's really server-only thing.

On the other hand, app folder contains lots of stuff that is actually shared across frontend and backend.

.output/
.nuxt/
content/
layers/
modules/
plugins/          <- I've moved plugins out on the same level as modules
node_modules/
public/
client/
  assets/
  components/
  composables/
  layouts/
  middleware/
  pages/
  main.vue
  router.options.ts
shared/
  utils/
server/
  api/
  middleware/
  plugins/
  routes/
  utils/
nuxt.config.ts

But I actually prefer the current structure over this 😅

@Atinux

give more separation for the "app" level

could you probably give us more insights on what kind of separation for the app level you meant, and what kind of problems we're trying to solve here?

from nuxt.

I do this already for all my Nuxt apps and find it really helpful.

I use “app” as the top level name

from nuxt.

I like it. The root became a little convoluted. This makes clearer what's server and what's client

from nuxt.

My initial thought was app as it's familiar from other frameworks, but I think the backend is very much part of the "app" and so that name still leaves things a little muddy.

I vote ui.

ui/
   app.vue
server/
   routes/
nuxt.config.ts

from nuxt.

I agree with the proposed structure, but I also believe that there's the need to have some utils/ and types/ shared between app/ and server/.

Also, since content is not part of "Nuxt core", you could showcase a full example with other common modules like i18n.

Thank you for your time! 🤗

from nuxt.

@manniL
Thanks for replying to everyone !

For now, Nuxt and Nitro are tightly coupled, but I'd like to imagine a (distant) future where it would be possible to configure this, and use a different server engine (Laravel, Django, Elysia ...) officially through a configuration option. Since we support multiple bundlers, we could attempt multiple servers. If that ever happens maybe both Nitro and the other server would be present, so having this directory structure would remain clear.

app/router.options.ts would fit like a glove in the new .config directory, with every other configuration file.

App.vue is a great option too.

You're right with tests, it's very opinionated. We can be flexible as they will be detected anywhere anyways.

One more word regarding the relation between nuxt and nitro : Even though they are worked on by the same people, they are separated projects that lives in different repositories, with separated documentation. Having that distinction present in the directory structure makes it crystal clear.

I also like that this makes communication explicit for features that have the same name but are different : "Route middleware are ... This happens in the Nuxt part of your app" or "Server middleware are ... this happens in the Nitro part of your app".

You could argue that this directory should be named vue or even app, but I think nuxt is a pretty good name.

@AymericB305 I would argue that Nuxt and Client are really different : Nuxt should be understood by all as a meta framework, SSR framework or universal framework, meaning that you can write something in /page that will be SSRd.
To me it feels like that nuxt would fit a directory name that could contain server code, and is a little bit more specific than app.

from nuxt.

IMO, considering that already Nuxt 3 uses the client/server nomenclature in some places, I guess that would be the correct option. Otherwise, other things such as the ClientOnly component would also have to be changed to whatever new nomeclature we use in V4.
That being said, I guess app wouldn't work well because it would feel like server is outside of the app, and it's not.
Therefore other good options I saw were nuxt (but might be confused with .nuxt), ui and web

from nuxt.

I'd love to see pi0's .config proposal implemented in v4!

from nuxt.

@danielroe I'm looking the nuxt docs and pi0's proposal but I can't seem to find any documentation about the config dir.
Is there a page I can check or a repo to use as example? (supported files, naming convention, etc)

from nuxt.

@NicolaSpadari We support loading Nuxt config from .config/nuxt.ts or .config/nuxt.config.ts.

from nuxt.

@NicolaSpadari I believe what you're looking for is written here: https://github.com/pi0/config-dir. 🤗

from nuxt.

Since we are discussing directory structure, I would like to bring up an idea about perhaps pages should be called views. Since we are building full-stack apps now not only webpages. When reading the Nuxt documentation, it often describes building an application (emphasis on application). And when reading the section about pages it says the following:

Pages represent views for each specific route pattern.
https://nuxt.com/docs/getting-started/views#pages

I have always found it a bit odd that these "views" are called pages. Perhaps this comes from the term "webpage" or a classical website where a user browsers multiple pages. But since we are building apps with Nuxt, the term pages seems to be limited to the idea of a webpage. Many modern web apps looks more and more like native desktop apps and they certainly don't have pages so calling them that is a bit misleading. For example - there is no "pages" in Photoshop.

And since Pages represent views, why don't we call them views? I think views would work for both - classical web pages and modern web apps. In fact, I think pure Vue with Vue Router used to encourage to create a views directory for multiple routes. I wonder why Nuxt decided to call them pages instead.

I think this topic deserves a discussion and we should try to approach this with an open mind. Perhaps we're too used to calling them pages by now but I for one would vote for calling them views. But maybe pages sounds more friendly. 🤷🏻 What do you think?

from nuxt.

Ok i thought it was already implemented in nuxt for multiple config files.
I understand it's a proposal that libraries themselves have to adopt, thanks for the clarification

from nuxt.

I think it's change and not a lot of change

from nuxt.

I'm also expecting app router like next 14 and route group. now if we need auth routes in auth folder then route become

/auth/login
/auth/register

it will be good if

pages/
    (auth)/
        Login.vue
        Register.vue

route now should be

/auth/login
/auth/register

Only index.vue accessible in router

pages/
    (auth)/
        Login/
            index.vue
            style.css

I believe in the second scenario you wanted the paths to be:

/login
/register

as the (auth) directory is just for grouping purposes, I had the same request, actually, so yes that would be nice.

from nuxt.

@hbilal9 Is there a workaround to do this now? I don't want to define an alias in each page independently.

from nuxt.

Hey all 👋🏻

Thanks a lot for all your input and suggestions! I wanted to comment and share my personal opinion with regard to some of these here ☺️

@eunjae-lee

In my mind, Nuxt app is a combination of vue's frontend and the backend. So seeing app and server separately makes me feel like this server is something outside this Nuxt app.

I'd say you could simply take the server folder and run it a standalone Nitro app, yes. But of course, for SSR'ing your Nuxt app, Nitro is "needed", same for running Nuxt plugins on the server side. But this code is all in the app folder anyway. I tried explaining that a bit ago here.

But I like the server being separate as it's really server-only thing.

This exactly!

On the other hand, app folder contains lots of stuff that is actually shared across frontend and backend.
I've moved plugins out on the same level as modules

I think moving plugins up isn't the way to go, as "Nuxt plugins" should stay within the Nuxt app while Nitro plugins belong in the server folder as these are two fundamentally different plugin types. ☺️

could you probably give us more insights on what kind of separation for the app level you meant, and what kind of problems we're trying to solve here?

I am not @Atinux but separating the Nuxt app from the server helps understanding the "boundaries" between your "Nuxt/Vue" part (even if it might be SSR'ed) and the "server" part a bit more. Lots of people try using pinia or Vue composables in /server, which could be less tempting with the new structure from my POV.

@wajeht app will be treated as srcDir "internally".

@therealokoro client might suggest that the application is client-only, but as Nuxt is capable of SSR and the content in that folder will be SSR'ed, it could trip off people IMO.

@Hebilicious

How about nuxt ?

Would that mean that Nuxt can "exist" without nitro or that Nuxt "does not include Nitro"? 🤔

* `app/router.options.ts` feels out of place

Where else would you put it? 🤔

* difference between `utils` and `composables` ?
* why not get rid of both utils and use `composables` everywhere?

The difference is a big one semantically (e.g. explained in this video) - happy to see clear separation there.

* why `main.vue` and not `index.vue` ?

The name of the "App.vue" replacement is still to be discussed. I personally think App.vue would still suit the best as index.vue could be confusing (as it is not file-system based routing) and hard to find (when using fs-based routing you have so many index.vue)

* where would `tests` go ? That should be part of the directory structure imo

IMO:

• Unit tests folder - nowhere, tests close to your components, ___tests__ if necessary
• E2E-tests top-level.

Instead of app and server, I suggest nuxt and nitro ? This makes things clearer imo :

• The more I think about it, the more I begin to like that! 🤔 Only the first question (Would that mean that Nuxt can "exist" without nitro or that Nuxt "does not include Nitro"? ) isn't resolved with that.

/app/app.vue -> /app/render.vue
Since it duplicates the name app, it’s not nice, I suggest changing it to render since it renders the server and the client

from nuxt.

FWIW I've been doing a lot of work with layers recently (on my 4th project with them) and as great as they are in some aspects, there are various inconsistencies and gotchas regarding path formats, core config options, auto-imports, etc, etc.

My feeling is: get these problems addressed, then you don't need to worry about the "perfect folder structure", as everything becomes a layer – whether it's a global root layer, or any other combination of nested layers – and Nuxt has a way to register everything it needs, a much improved experience for the user or team – and I'm guessing – less gymnastics in core Nuxt code.

from nuxt.

I would suggest focus on stability, performance and real new features, not wasting everyone's time in learning a new folder structure, while it has no overall benefits, rather than some few individual prefer it one way.

@Shooteger the folder structure will be customizable, so you won't need to learn a new structure, you will be able to use your exisitng one. It will be configurable.

from nuxt.

I hope the new directory structure will bring more raw performance improvements to the various existing javascript runtimes, thanks nuxt team

from nuxt.