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.

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

[LovesWorking]

marklawlor

@marklawlor @EvanBacon

Cameron Olivier makes a great point, and I completely agree. Developers should have the flexibility to structure their routes and organize their apps in the way that best suits their needs. Expo shouldn’t enforce an opinionated approach by labeling colocation as an anti-pattern, especially when many in the community see value in it.

React itself is built on the principle of unopinionated flexibility, allowing teams to structure their apps based on what works best for their specific needs. Expo should embrace this philosophy instead of dictating (x) approach.

If Expo Router isn't going to support colocation despite clear demand from the community, it's clear that Expo prioritizes its internal preferences over developer experience. Many frameworks have moved towards more flexible routing systems, why should Expo be the exception?

Instead of deciding what’s "right" for all apps and developers, why not give developers the option? That way, teams can work in a way that aligns with their preferences.