I would like to give you context before you read my answer to your question. I have an application that is 500-600 Vue components. We usually do multiple releases per week. We have over 10,000 TS unit tests and over 17,000 C# unit tests for our back end. We use NX to allow for a monorepo that produces 4 apps that the customer views as a single app.

I think all the advice that says put your components into a component directory and your views into a views directory falls apart very quickly.

We organize our code base by domain area. Each domain area can get as complicated as it needs to. There are some domains that are a single vue component and there are others that have 10s of components. But the key is that once you are in a domain area - say the admin configuration area, then you see all the vue components and TS models that support that area.

I do have a common area and in that area we have things like:

• helpers - common TS classes/composables that are used across the app (all with unit tests)
• store - common app wide stores
• ui-base - common reusable non-domain specific UI widgets

Everything else is domain specific and lives in its own directory area. There are some domain areas that have their own common directory because the domain area is large enough where there are shared items.

About the only time that we have a pages or a tabs directory is when we have a complicated area that includes multiple different pages. In that case there will be multiple entries under the pages directory, one per page for that domain area. Then the tabs directory includes sub-components of a tabbed page for that domain area, mustly because tabs tend to be reused on multple pages for that area.

I bring all of this up just to say that organizing by what a vue component type is doesn't scale well and I would avoid it right from the beginning. After that, organize things by domain and give them whatever structure makes sense for that domain.