vite: `vite.config.ts` can't import untranspiled ts files from other packages in the same monorepo

Are we still looking at it? because it is very useful when it comes to monorepo and workspaces. Even more so when we can create and use plugins in simple and shared ways within the project.

If you want to use a monorepo/workspace with typescript, you should set it up correctly using project references with compilerOptions composite: true, since you can’t import an untranspiled .ts file in a transpiled module. Every module (like a plugin) you import into vite.config.ts is already transpiled to js. Even without vite, the projects need to be referenced. While developing you should use ts-node or tsx, so you don’t need to rebuild the files all the time.

There are many different ways to set up a working typescript workspace. I created an example vite-typescript-monorepo.

May be true, but the expectation from a user’s point of view is a little different. If typescript support for configs is coming out of the box, it should be supported fully. In my point of view there’s only two ways of solving this:

1. Remove TypeScript support to avoid “misusage”
2. Make it work 😉

🤷🏻 it’s not much tbh. compared to the drama llama of your current situation, i’d happily pick preconstruct.

What worked as a workaround for me was using a relative import inside the monorepo instead of absolute package paths. So assuming you have a monorepo with app/ and plugin/ in root packages/, in packages/app/vite.config.ts instead of importing

import MyPlugin from '@me/plugin'

just used

import MyPlugin from '../plugin'

It’s not ideal since you are importing from outside of your package, so still hoping this issue gets a proper fix in Vite.

I just realized that we could use a loader like esbuild-register for config loading.

I’m not sure if we can use esbuild-register directly. For now, I can think of a few edge cases:

1. Each TS module’s tsconfig.json isn’t correctly respected. We need to reuse https://github.com/dominikg/tsconfck for that.
2. Plain JS modules that aren’t in the project should not be transpiled by esbuild due to performance concerns.

Anyway, this is a low-priority but doable feature. We can fix it when we are going to refactor the configuration loading logic in the future.

Just remembered of jiti, and it seems to have the mechanism we need to programmatically load the config, and addresses my previous comment’s concern. jiti however seems to have a rather large bundle size. We could probably implement something simlar, leveraging our own esbuild API too. So maybe there’s a way to solve this and #9202.

use preconstruct on your packages… then you can just sidestep all this headache.

https://preconstruct.tools/

it sets up mjs and cjs stubs that behave differently in development than in production. 👍🏻

Now that vite 3 is using esm, I’m getting an issue with importing *.ts files in monorepo packages (TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".ts"). The “right” answer is to compile the *.ts files. I would love to avoid the extra build step, as it takes development maintenance, time, complexity, & makes the DX considerably worse. Bun will handle this but it’s is 6+ months away. At this point, what would be the best way to import *.ts files without having to compile those files? I get that it’s a low priority & the “right” answer is to compile the *.ts files, but it sure would be great if it were not necessary.

TSX has been working great for running from the cli. Importing *.ts from monorepo packages worked in vite v2. Now how do we get the automatic transpilation of *.ts back in vite3 + nodejs?

There seems to be a confluence of underlying approaches which cause this problem. The need to automatically transpile ts to js. The need to use a monorepo with separate npm packages. The need to have a quick build…etc

May be true, but the expectation from a user’s point of view is a little different. If typescript support for configs is coming out of the box, it should be supported fully. In my point of view there’s only two ways of solving this:

1. Remove TypeScript support to avoid “misusage”
2. Make it work 😉

Agreed. The problem with partial support for TypeScript is that the support becomes a moving target…such as the ERR_UNKNOWN_FILE_EXTENSION regression between v2 & v3…which makes for some nasty surprises when upgrading.

This solution has worked for me:

https://github.com/privatenumber/tsx

"NODE_OPTIONS='--loader tsx/esm' vite ..." // node 18 "NODE_OPTIONS='--import tsx' vite ..." // node 20

I’ve recently run into same/similar problem when using a pnpm monorepo with some custom/user exports conditions in package.json. I tried to work around this limitation with a DIY solution of my own. I first digged into vite’s code itself that allows TS support for config files to check if I can customize it, and then I decided to graduate the DIY workaround to its own npm package called import-single-ts.

At the moment that’s how I set up the vite config in the porjects of my monorepo:

1. I rename my vite.config.ts to vite.config.original.ts
2. I create a js file called vite.config.js with contents of:

   import { importSingleTs } from 'import-single-ts';
   
   export default (await importSingleTs('./vite.config.original.ts')).default;
   

And that’s it. It is inspired by how vite does this internally + how esbuild’s node-resolve plugin works .

Pros of import-single-ts for the vite.config.ts usecase:

Some benefits compared to solutions suggested earlier in this thread:

• No need to use relative imports in a monorepo, just use the normal import path
• No need to patch vite’s dist files
• No need to include a global transpiling runtime like @babel/register, esbuild-register or jiti.register() which latch on require.extensions, add overhead and seem to be deprecated in node
• It works for both ESM and CJS packages in my monorepo
• It is very simple, just a single file (take a look!) using things that vite already has like esbuild.

Cons of import-single-ts for the vite.config.ts usecase:

You have an additional almost empty proxy viter.config.js file but I can live with this for now 🤷 .

Final thoughts

I wonder if vite’s team is open to use enhance-resolve since this worked for me pretty much out of the box. There could already be such discussion, I know enhanced-resolve is created by webpack and vite has its own resolution logic and of course I don’t know the differences, I just saw that enhanced-resolve worked for me so I’m mentioning it.

In my specific use-case as I mentioned I use custom exports conditions which I define like this in the vite.config.js:

import { importSingleTs } from 'import-single-ts';

export default (
  await importSingleTs('./vite.config.original.ts', {
    // this is the additional piece when compared to the first code example
    conditions: ['antitoxic-dev'], 
  })
).default;

@airtonix does that not need to setup babel and stuff to compile everything? The whole reason we use Vite is for the dx and no need to setup a lot of additional babel stuff.

Just wanted to put out another option that I see mentioned once but as something to look for in the future - I’ve simply swapped to using bun to run Vite, and there isn’t any issue anymore…

This is where I found how to use bun with vite: https://github.com/bluwy/bun-vite-ts-test/blob/master/package.json

If you want to use a monorepo/workspace with typescript, you should set it up correctly using project references with compilerOptions composite: true, since you can’t import an untranspiled .ts file in a transpiled module. Every module (like a plugin) you import into vite.config.ts is already transpiled to js. Even without vite, the projects need to be referenced. While developing you should use ts-node or tsx, so you don’t need to rebuild the files all the time.

There are many different ways to set up a working typescript workspace. I created an example vite-typescript-monorepo.

This is precisely the point of preconstruct.

Feels like everyone is trying to reinvent nodejs to avoid using preconstruct?

because there are several problems here you can keep using your project references with preconstruct.

1. how do you speed up vscode intellisense resolving and compiling? tsconfig references
2. how do you resolve packages? either: a. a root tsconfig with all the monorepo packages listed in paths, or b. just use normal nodejs way where each package has it’s own package.json and then you use preconstruct to provide easy no-compile access to ts and non ts tooling.

If you go for 2.a, then you cant dogfood your own typescript tooling packages with any tooling you use that doesn’t know how to typescript.

because of that, i choose to work with preconstruct

We’re facing the same issue at Nx. Related issue: https://github.com/nrwl/nx/issues/17019#issuecomment-1561452476

and repro: https://github.com/mandarini/vite-paths

For myself, I found a workaround for loading a ts file in vite.config.ts . I import the ts file through js (js file like a proxy)

// root/vite.config.ts

import { funcFromTsModule } from './moduleForViteConfig'
export default ({ mode }) => {
    funcFromTsModule('example')
    return defineConfig({
        build: {
            ...
        },
        server: {
            ...
        },
        plugins: [
        ],
        ...
    })
}

// root/moduleForViteConfig/index.js

export * from './src'

// root/moduleForViteConfig/src/index.ts

export const funcFromTsModule = (str: string) => 'bar' + str

@kdembler your workaround works for me too, I don’t like it but until Vite can fix this issue it’ll have to do, this is definitely the simplest workaround I’ve found so far, thanks!

@btakita

Agreed. The problem with partial support for TypeScript is that the support becomes a moving target…such as the ERR_UNKNOWN_FILE_EXTENSION regression between v2 & v3…which makes for some nasty surprises when upgrading.

I couldn’t agree more, partial support for TS is a deal breaker in so many open source projects these days, either support it 100% or don’t, there is really no in between.

We also encounter this problem. Our use case is that we have a monorepo with 5 micro-frontends (vite apps). We want to have 1 base vite config file and extend from that. It would be really nice to have an option to import and/or extends other config files in .ts format without compiling first.

Anyway, we ended up writing the base config file in plain js with module.exports.

• vite.apps.base.js

const react = require("@vitejs/plugin-react").default;

module.exports = function ({ root, isDev, plugins }) {
  return {
     ...
      resolve: {
       alias: {
         src: path.resolve(root, "src"),
       },
     },
     plugins: [
         react({
          babel: {
            plugins: [
              [
                "babel-plugin-styled-components",
                {
                  displayName: isDev,
                  fileName: false,
                  ssr: false,
                  minify: !isDev,
                  transpileTemplateLiterals: !isDev,
                  pure: !isDev,
                },
              ],
            ],
          },
        })
       ...more plugins
      ...plugins
     ]
  }
... more options
}

and then we could use like this:

import base from 'config/vite.apps.base';

// https://vitejs.dev/config/
export default defineConfig(({ mode }) => {
  const isDev = mode === 'development';

  return base({
    root: __dirname,
    isDev,
    plugins: [
      partytownVite({
        dest: path.resolve(__dirname, 'build', '~partytown'),
      }),
    ],
  });
});

Just remembered of jiti, and it seems to have the mechanism we need to programmatically load the config, and addresses my previous comment’s concern. jiti however seems to have a rather large bundle size. We could probably implement something simlar, leveraging our own esbuild API too. So maybe there’s a way to solve this and #9202.

Interesting. Tailwind had similar issues to this very ticket (https://github.com/vitejs/vite/issues/5370), they addressed it with jiti.

This solution has worked for me: https://github.com/privatenumber/tsx "NODE_OPTIONS='--loader tsx/esm' vite ..." // node 18 "NODE_OPTIONS='--import tsx' vite ..." // node 20

works for me, but requres node 18+, dependency tsx and permament setting NODE_OPTIONS env

As an alternative, relative path will work and requires 0 setup. In our team we’ll wait until out-of-box solution and then replace relative path to package name

// vite.config.ts
// @see https://stackblitz.com/edit/vitejs-vite-lpsoay?file=main.js

import { defineConfig } from 'vite';
// won't work
// import { defaultConfig } from '@foo/tools';
// If use relative import instead of local workspace library, it'll work
import { defaultConfig } from './tools';

export default defineConfig(() => {
  return defaultConfig;
});

PS: Using Bun instead of Node.js also good alternative

Thanks for sharing @maximan3000 ❤️ Solved my issue importing a typescript remark plugin into my astro.config.ts

❌ Not Working: absolute path

import { remarkDateToday } from 'src/plugins/remark/date-today'

✔️ Working: relative path

import { remarkDateToday } from './src/plugins/remark/date-today'

This solution has worked for me:

https://github.com/privatenumber/tsx

"NODE_OPTIONS='--loader tsx/esm' vite ..." // node 18 "NODE_OPTIONS='--import tsx' vite ..." // node 20

works for me, but requres node 18+, dependency tsx and permament setting NODE_OPTIONS env

As an alternative, relative path will work and requires 0 setup. In our team we’ll wait until out-of-box solution and then replace relative path to package name

// vite.config.ts
// @see https://stackblitz.com/edit/vitejs-vite-lpsoay?file=main.js

import { defineConfig } from 'vite';
// won't work
// import { defaultConfig } from '@foo/tools';
// If use relative import instead of local workspace library, it'll work
import { defaultConfig } from './tools';

export default defineConfig(() => {
  return defaultConfig;
});

PS: Using Bun instead of Node.js also good alternative

I also had this issue (a shared config that I want to import in several other workspaces), but just realized today that the simplest solution for us was to write the shared file as *.mjs and swap Typescript for JSDoc to keep type safety and intellisense.

I realize this might be more work with shared plugins but for colocating a shared config, it was a breeze ✌️

// vite.config.shared.mjs

/** @type {(rootDir: string) => import('vite').UserConfig} */
export const sharedViteConfig = (dirname, pkgName, pkgVersion) => ({
  /* shared config here */
});

If you want to use a monorepo/workspace with typescript, you should set it up correctly using project references with compilerOptions composite: true, since you can’t import an untranspiled .ts file in a transpiled module. Every module (like a plugin) you import into vite.config.ts is already transpiled to js. Even without vite, the projects need to be referenced. While developing you should use ts-node or tsx, so you don’t need to rebuild the files all the time.

There are many different ways to set up a working typescript workspace. I created an example vite-typescript-monorepo.