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 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

[cameronolivier]

Adding to this - this makes sense for the simplest of routing/apps. As soon as you add any complexity you run into a potential nested horror story.

Example:
A typical app would be using redux (or some state management). Along with Redux you might have style files, test files, route-specific components, route-specific utilities or constants, etc - depending on the general approach one may have taken with FE architecture.

For a given route, it's common to have:

app
└── home
    ├── components
    │   ├── userProfile.tsx
    │   ├── userProfile.test.tsx
    │   ├── userProfile.styles.tsx
    ├── index.tsx
    ├── home.test.tsx
    ├── home.reducer.tsx
    ├── home.middleware.tsx
    ├── home.reducer.tsx
    ├── home.styles.tsx
    └── home.selector.tsx

etc.

We've had routes with complex forms etc that need to be broken up (but are specific to that route).

I've found success with Tanstack Router (which is both directory and file-based) where one can wrap all non-route files away - but keep them collocated.

app
└── home
    ├── -files
    │     ├── components
    │     │   ├── userProfile.tsx
    │     │   ├── userProfile.test.tsx
    │     │   ├── userProfile.styles.tsx
    │     ├── home.test.tsx
    │     ├── home.reducer.tsx
    │     ├── home.middleware.tsx
    │     ├── home.reducer.tsx
    │     ├── home.styles.tsx
    │     └── home.selector.tsx
    └── index.tsx

The alternative here would be to either run parallel directory structures (or some flattened version) or give up on collocation altogether and spread these files to the wind...

Parallel

this quickly gets out of hand if you have deeply nested routes (excuse the forced example)

app
└── home
   └── user
   └── user-profile
   └── user-profile-edit
modules // or pages or routeFiles, etc
└── home
    │     ├── user
    │      │     ├── ....
    │     ├── user-profile
    │      │     ├── ....
    │     ├── components
    │     │   ├── userProfile.tsx
    │     │   ├── userProfile.test.tsx
    │     │   ├── userProfile.styles.tsx
    │     ├── home.test.tsx
    │     ├── home.reducer.tsx
    │     ├── home.middleware.tsx
    │     ├── home.reducer.tsx
    │     ├── home.styles.tsx
    │     └── home.selector.tsx
   ...

To The Wind (grouped by what not where):

app
└── home
   ├── user
   ├── user-profile
   └── user-profile-edit
reduces // or pages or routeFiles, etc
├──  home.reducer.ts
├── user.reducer.ts
└── ...
selectors
├──  home.reducer.ts
├── user.reducer.ts
└── ...
components
├──  routes
    └── home
       ├── user
       ├──user-profile
       ├──user-profile-edit
      └── ...
├──  common
    │     ├── ....
tests
.... 
utils
...

being able to group within routes - even at a higher level - would be supremely useful. We can already use (group) syntax, and /index.tsx as well - allowing you to effectively create a directory-based routing structure. It simply doesn't feel like including the ability to co-locate files specific to routes but which should not be routes is that far outside of the features already available (And would be super useful in simplifying the navigation of the overall directory structure in the app leading to better DX and onboarding).

PS: Please excuse any issues with the directory structures - they were tedious to handroll...

[anicioalexandre]

Desired Approach

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

In the sign-in-form.tsx, what if we avoid using a default export for the component? According to the Expo router documentation:

A route file is defined by exporting a React component as the default value.

@marklawlor, do you think this approach could negatively affect performance during expo scanning process, especially in larger projects with many non-route files, or is the impact negligible?