-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improved Directory Structure #26444
Comments
Shouldn't we also move the |
Not sure for 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' |
Love it! 💚 What will be the best approach to share common utils that can be used in |
I would say in |
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. |
I believe we can easily detect the old format and have a way to upgrade to the new one by running either |
I guess also a |
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. |
Can we keep server/plugins/ for server plugins? 👀 |
@Lootjs yes, |
sigh of relief |
We're also discussing ideas like |
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?
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. |
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. |
In my mind, Nuxt app is a combination of vue's frontend and the backend. So seeing On the other hand,
But I actually prefer the current structure over this 😅
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? |
@danielroe How about nuxt ? :D Reposting my thoughts from the initial discussion : I really like the fact that we now have I think that if we are changing the structure, we should consider more changes and bring in more benefits.
Instead of
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 |
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. |
As said by someone above, I feel Now the question would be.... "Where should the modules folder go?" In my opinion, since a module can contain both server and client code, then it should be on same level as the 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. |
can we include a
|
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
I'd say you could simply take the
This exactly!
I think moving
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 @wajeht @therealokoro
Would that mean that Nuxt can "exist" without nitro or that Nuxt "does not include Nitro"? 🤔
Where else would you put it? 🤔
The difference is a big one semantically (e.g. explained in this video) - happy to see clear separation there.
The name of the "
IMO:
|
|
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 To me, reflecting the Nuxt and Nitro contexts onto the directory structure makes the whole thing simpler to understand and also to communicate. |
Before I read this issue fully my gut reaction was it should be 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 I‘ll cast my vote towards |
I do this already for all my Nuxt apps and find it really helpful. I use “app” as the top level name |
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 |
Here's my take:
That said, I believe app would be a more appealing default option. The only drawback here is |
@NicolaSpadari I believe what you're looking for is written here: https://github.com/pi0/config-dir. 🤗 |
Since we are discussing directory structure, I would like to bring up an idea about perhaps
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 And since 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 |
@martinszeltins — a quick opinion on 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]). |
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. |
Ok i thought it was already implemented in nuxt for multiple config files. |
I'm also expecting app router like next 14 and route group. now if we need auth routes in auth folder then route become
it will be good if
route now should be
Only index.vue accessible in router
|
I think it's change and not a lot of change |
I think Middleware is just more proper English. |
I believe in the second scenario you wanted the paths to be:
as the |
@mahmoudyusof exactly |
@hbilal9 Is there a workaround to do this now? I don't want to define an alias in each page independently. |
/app/app.vue -> /app/render.vue |
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. |
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. |
@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. |
@Shooteger Please don't assume we're just making a change because 'some few individuals prefer it one way.' The change aims to improve:
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. |
@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? |
@danielroe But as you just stated now, it is optional with automatic fallback and therefore not the case. Thank you very much and peace 😎 |
Lots of love, peace, health, and success to the amazing Nuxt team. 💚🔥👏🎉 |
I hope the new directory structure will bring more raw performance improvements to the various existing javascript runtimes, thanks nuxt team |
Where would I place |
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:
Do you see any downside of this approach?
The minimal starter would then be:
The text was updated successfully, but these errors were encountered: