Expo Router showing files in __test__ folders

[kyusungpark]

Hi, I been writing tests and been putting those tests in __test folders in their respective locations where the file in located. I noticed that when I develop locally with expo I don't see the test files, but when I do my run my build, I see the test files as Tabs within the app.

I did try (test) but this did not work either, is there a way to hide these tabs from expo router?
I like to have them in the same folder as the other files instead of creating a separate folder just for the tests.

[marklawlor]

Expo Router doesn't support non-route files in the app directory.

[marklawlor]

We recommend having a folder structure like so

/app
/components 

I don't understand your comment about having to update in two places, I'm assuming your talking about relative import paths? We recommend using path aliases to easily access components e.g import "@/components/<my-components>" and avoid relative import paths. The recent templates from Next.JS and Svelte Kit also adopt this pattern, as well as many starter templates from the community.

[alexgshaw]

Thanks for the quick response. That's not exactly what I'm referring to.

Here's an example of the dilemma I'm referring to. Say I have the following desired folder structure.

Desired Approach

app/
├── index.tsx
└── sign-in/
    ├── index.tsx
    └── components/
        └── sign-in-form.tsx

Well, with expo-router that is not possible. So the recommended approach would instead be one of these two options

Option 1

This is the approach you are recommending IIUC.

app/
├── index.tsx
└── sign-in/
    └── index.tsx
components/
└── sign-in-form.tsx

The problem is that as the app grows, the components folder becomes increasingly unmanageable because of its flat structure (which is not the case in the desired approach). You could easily end up with 100+ components in one folder.

So maybe you take a different approach:

Option 2

app/
├── index.tsx
└── sign-in/
    └── index.tsx
components/
└── sign-in/
    └── sign-in-form.tsx

This solves the flat components folder problem, but now whenever I want to change a route, I have to make edits in two places and update the imports in my route. In general, this is a lot of overhead and you run into the risk of your components and app directories falling out of sync.

Can you give me an example structure that doesn't run into those issues? If not, I think expo-router should seriously consider allowing non-route files inside of the app directory. Maybe the behavior could be something like "if no default component is exported, then don't render as a route" or have some prefix that can be put on a folder to not render it as a route, e.g. ^.

(I'm a huge fan of the push for expo-router and directory-based routing, which is why I'm adding my two cents)

[marklawlor]

We recommend option 2.

I can understand your concerns but I believe your example is too simple and does not represent the typical structure of a native application. Most native applications will use shared routes (as opposed to a web application where they are not as common). When using shared routes the "route file" will exist in multiple places, not a single directory, so users will be using a "components" folder.

At this stage we're very unlikely to change to a completely different architecture. We know the pros/cons and the possible solutions - Expo Router has been in development for a while! But we like the direction we're currently moving and are unlikely to change.

Couple of last comments

• The downside of renaming files/imports is mostly offset modern editors, which will move a file and update all imports for you. If you find this frustrating this might be the solution for you.
• From my experience, keeping /routes and /components in sync ends up being an anti-pattern. Grouping components by functionality, not physical route name, works much better. This will often grow into something similar to atomic design. But as multiple routes can display the same page, its not ideal to tie routes and pages together
• We are already uncomfortable with the number of "filename" rules and special exports that Expo Router has. Adding more rules just adds extra complexity and requires specialised knowledge. We're seeing other frameworks also move away from them, so this seems to be a shared sentiment across the community.
• We're not against co-location and plan to use them when appropriate. For example we're exploring platform specific route files.

[khenkel-daxko]

Hi, I'm aware this discussion is a few months old already, but I'd like to add more thoughts here.
It's a common pattern to have test files next to their to-be-tested components, like this:

app
├── home
│   ├── user.test.tsx
│   └── user.tsx
├── index.test.tsx
├── index.tsx
├── sign-in.test.tsx
└── sign-in.tsx

With the current routing system Expo doesn't support this. My proposal is for this to be configurable in the app.json file. Next.js solves the same problem by making pageExtensions configurable. This way you can define that all routes have to end with e.g. .page.tsx to be considered as a route, and everything else will be ignored.

[marklawlor]

To add another layer to this discussion, we are looking at supporting platform extensions for routes. This means you could have this structure

app
└── home
    ├── user.tsx
    ├── user.android.tsx
    ├── user.ios.tsx
    └── user.web.tsx

If we added .test files, the structure will now be

app
└── home
    ├── user.tsx
    ├── user.test.tsx
    ├── user.android.tsx
    ├── user.android.test.tsx
    ├── user.ios.tsx
    ├── user.ios.test.tsx
    └── user.web.tsx
    └── user.web.test.tsx

I like co-location, but having eight files for a single route feels excessive. Also .test.tsx is not a standard in React Native. For example jest-expo use -test.<platform> to improve readability with platform extensions. This makes things harder because what if you have a route that ends in -test?

I'm a fan of Next.js, but the ecosystem in React Native is different, so concepts will not translate 1-1