Next.js compiles .ts files outside of the application directory, but not .tsx files

Bug report

Describe the bug

Next.js supports TypeScript, which means that it is able to load .ts and .tsx files from within the application directory. In addition, Next.js also supports loading files from outside the application directory, e.g. to be able to use shared components. However, this only works for .ts files, not for .tsx files. This is unexpected and makes it hard to work with re-usable UI components, without having to come up with a separate npm module for them, which is often not what you need.

To Reproduce

We have set up a sample repository with a small, but complete example to reproduce the issue. Please see https://github.com/thenativeweb/temp--next-issue for details. The README.md file contains the detailed description on how to reproduce the issue.

Expected behavior

Next.js should not only support .ts files from outside the application directory, but .tsx files as well.

System information

• OS: macOS Big Sur (11.0.1)
• Version of Next.js: 10.0.3
• Version of Node.js: 14.14.0
• Deployment: npx next

Additional context

Setting up a separate npm module for the shared components is definitely not what we want to use. Even the various Next.js applications we have shall be in a single npm module, as they get started altogether using a custom server. So in the end, although our “real” repository contains multiple Next.js applications, there is only one actual application in the end. This is also the reason why we don’t want to go down the next-transpile-modules road (it would force us to introduce separate modules as well).

Given that Next.js is able without any ado to handle .ts files from outside the application directory, we assume that the same should be possible for .tsx files.

[Timer]

We shouldn’t support importing .ts files, so we probably need to fix this behavior to be in line with .tsx.

[Timer]

I’ll provide additional background:

Next.js currently only compiles assets that it considers to be first-party to your application. i.e. packages within the project root where next build is invoked from.

This was an intentional design decision and is in-line with other tools like Create React App (FWIW CRA has an even stricter restriction of forbidding even .js outside of root).

The thought process behind this decision is that code outside of your project’s directory may be on different version(s) of packages or using different syntax features not yet supported by Next.js, e.g. React 16 vs 17 (using the new JSX transform) or TypeScript 3 vs 4 (using new syntax features).

The code for projects outside of Next.js’ project root, even in the same monorepo, should be precompiled with their own tooling (e.g. tsdx) so that Next.js can consume it as it would something from node_modules.

This eliminates the need for you to upgrade all your Next/React/TypeScript/etc versions in tandem across a potentially large monorepo, i.e. it provides isolation by ensuring assets are compiled down to a common interop language: ESLatest JS (same as node_modules).

---

With the above background stated, I’m treating this issue as a bug report because the current design intent is not to allow .ts imports (or .tsx) outside of the project root.

This doesn’t mean we’re not considering allowing this, and we have an issue open to track allowing this behavior: https://github.com/vercel/next.js/issues/9474

We realize that small monorepos / certain organizations are ok with having to update all their TypeScript/etc versions in tandem, so we’ll let people opt-into this behavior.

You can track this issue (#9474) which would be the feature request version of this issue: to allow importing .ts and .tsx outside of project root.