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

zheeeng · 2021-10-21T07:21:20Z

Describe the bug

If we import something from symlink and the importee is ts file. We counter a such error:

failed to load config from /Users/zheeeng/Workspace/foo/bar/baz/vite.config.ts
error when starting dev server:
TypeError: defaultLoader is not a function

There are two workarounds: compile the ts file to the common js file, or specify the importee path to its real file path rather than symlink.

How could we use it without these two approaches?

Reproduction

https://github.com/zheeeng/test-symlink-vite-config

System Info

Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 1.60 GB / 16.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 14.17.0 - ~/.nvm/versions/node/v14.17.0/bin/node
    Yarn: 1.22.11 - ~/.nvm/versions/node/v14.17.0/bin/yarn
    npm: 6.14.13 - ~/.nvm/versions/node/v14.17.0/bin/npm
  Browsers:
    Chrome: 95.0.4638.54
    Safari: 14.1.2

Used Package Manager

pnpm

Logs

failed to load config from /Users/zheeeng/Workspace/foo/bar/baz/vite.config.ts
error when starting dev server:
TypeError: defaultLoader is not a function
    at Object.require.extensions.<computed> [as .ts] (/Users/zheeeng/Workspace/foo/node_modules/.pnpm/vite@2.6.5_less@4.1.2/node_modules/vite/dist/node/chunks/dep-55830a1a.js:68633:13)
    at Module.load (internal/modules/cjs/loader.js:933:32)
    at Function.Module._load (internal/modules/cjs/loader.js:774:14)
    at Module.require (internal/modules/cjs/loader.js:957:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/Users/zheeeng/Workspace/foo/web/studio/vite.config.ts:37:32)
    at Module._compile (internal/modules/cjs/loader.js:1068:30)
    at Object.require.extensions.<computed> [as .ts] (/Users/zheeeng/Workspace/foo/node_modules/.pnpm/vite@2.6.5_less@4.1.2/node_modules/vite/dist/node/chunks/dep-55830a1a.js:68630:20)
    at Module.load (internal/modules/cjs/loader.js:933:32)
    at Function.Module._load (internal/modules/cjs/loader.js:774:14)

Validations

Follow our Code of Conduct
Read the Contributing Guidelines.
Read the docs.
Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
The provided reproduction is a minimal reproducible example of the bug.

The text was updated successfully, but these errors were encountered:

haoqunjiang · 2021-10-25T03:45:29Z

Hi, we've discussed this issue at last Friday's team meeting.

Considering that:

I can't think of an efficient way to support this feature.
- The packages are excluded by esbuild because they're external.
- Most of the external packages used by vite.config.* don't (and shouldn't) require transpilation
- It's already a configuration file, we don't want to introduce another option to configure the loading logic of the configuration file.
The use case is quite rare. The logic in the configuration file is usually not very complex. Even if it is extracted to a separate package, I think it's acceptable to be written in plain JS or processed by an additional run of tsc.

So this feature would be a low priority for the team.
But feel free to open a PR if you can find a better and efficient way to handle this use case.

zheeeng · 2021-10-25T04:20:49Z

Thx for your discussion, I would try to transpile the ts config file.

zheeeng · 2021-10-25T05:38:27Z

@sodatea Can we add an environment variable for configuring this?

haoqunjiang · 2021-10-25T05:50:08Z

Environment variables are also a kind of configuration, so I don't think we should do that.

haoqunjiang · 2021-11-24T07:26:42Z

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:

Each TS module's tsconfig.json isn't correctly respected. We need to reuse https://github.com/dominikg/tsconfck for that.
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.

hiukky · 2022-03-10T03:23:42Z

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.

github-actions · 2022-03-28T05:23:55Z

Hello @zheeeng. We like your proposal/feedback and would appreciate a contribution via a Pull Request by you or another community member. We thank you in advance for your contribution and are looking forward to reviewing it!

julianklumpers · 2022-04-07T12:23:12Z

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'),
      }),
    ],
  });
});

airtonix · 2022-04-09T09:02:51Z

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. 👍🏻

julianklumpers · 2022-04-09T12:48:38Z

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

airtonix · 2022-04-11T02:24:01Z

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

black7375 · 2022-05-25T02:12:45Z

@airtonix Preconstruct seems to be a monorepo management tool that scaffolding can do.
I think this issue is close to tsconfig's extends or prettier's sharing configurations feature.

IMO, I think we need a feature like webpack-merge of webpack production doc

@julianklumpers
I'am using config builder pattern. (Temporary solution)

Library: https://github.com/black7375/vite-config-builder
Custom Config: https://github.com/black7375/ts-monorepo-template/tree/main/configs/vite-config-custom
Use Config: https://github.com/black7375/ts-monorepo-template/blob/main/packages/hello/vite.config.ts

bluwy · 2022-06-26T05:32:15Z

Wouldn't using something like esbuild-register pollutes the entire nodejs process? e.g. it would affect Vite SSR too which may bring a slight perf penalty, or perhaps inconsistency. Otherwise we'd need to spawn a child process to read the config, but that only works if the config is serializable.

I tried a different solution, by bundling the monorepo package when detected that the resolved path doesn't contain node_modules. It works but if the package defines it's own __filename or _dirname, it would break loading the config. Plus if you're linking Vite locally too, it'll have to re-bundle it entirely (also suffers from __filename issue).

Overall I'm also not sure if this is worth the complexity.

Hobart2967 · 2022-07-02T22:55:57Z

Same issue here.

I created 6 package projects within a Lerna workspace.
Additionally, I created a "config" package, which is symlinked to each. Importing the tsconfig as extends option works fine, also all other tools complain.

When it comes to vite, it states the above error message when importing and using the configuration function from that other config package.

I would really like to have and use this, it's very useful to have the same configs for each project ( all of them bundle the exact same way), shared as one config in one Central place.

Looks like I really need to convert the shared config to a JS file, loosing TS Support :(

jrson83 · 2022-07-03T04:24:10Z

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.

Hobart2967 · 2022-07-04T07:00:59Z

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:

Remove TypeScript support to avoid "misusage"
Make it work ;)

airtonix · 2022-07-13T00:00:18Z

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.

how do you speed up vscode intellisense resolving and compiling? tsconfig references
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

btakita · 2022-07-24T16:34:55Z

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:

Remove TypeScript support to avoid "misusage"

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.

smaven · 2024-05-15T13:59:03Z

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

Using "NODE_OPTIONS='--import tsx' works but vite does not watch for changes in the imported package of the monorepo.

// vite.config.ts

import { defineConfig } from 'vite';

// will work but vite won't HMR if @foo/tools change
import { defaultConfig } from '@foo/tools';
// HMR works with relative import
// import { defaultConfig } from './tools';

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

MQYForverT · 2024-05-16T02:33:20Z

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

Using "NODE_OPTIONS='--import tsx' works but vite does not watch for changes in the imported package of the monorepo.
// vite.config.ts

import { defineConfig } from 'vite';

// will work but vite won't HMR if @foo/tools change
import { defaultConfig } from '@foo/tools';
// HMR works with relative import
// import { defaultConfig } from './tools';

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

My alias configuration is as follows:
resolve.ts

import { resolve } from 'path'
import type { AliasOptions, ResolveOptions } from 'vite'
type IResolve = ResolveOptions & {
	alias?: AliasOptions
}
export function setupViteResolve(): IResolve {
	return {
		alias: {
			'@': resolve(__dirname, './src'),
		},
	}
}

vite.config.ts

import { ConfigEnv, defineConfig } from 'vite'
import { setupViteResolve } from '@mqy/vite-config/resolve'

// https://vitejs.dev/config/
export default defineConfig((configEnv: ConfigEnv) => {
	return {
		resolve: {
			...setupViteResolve(),
		},
	}
})

package.json

	"scripts": {
		"start": "NODE_OPTIONS=\"--import tsx/esm\" pnpm exec vite",
	},

but report a error：ReferenceError: __dirname is not defined
at setupViteResolve (/xxx/resolve.ts:9:17)

smaven · 2024-05-16T19:36:29Z

@MQYForverT I think the error is because __dirname is not defined in ESM. You can use import.meta.dirname instead (you might need need node > 20).

MQYForverT · 2024-05-17T04:05:15Z

@MQYForverT I think the error is because __dirname is not defined in ESM. You can use import.meta.dirname instead (you might need need node > 20).

thanks，But I also get errors when building, and I try to add NODE-OPTIONS="-- import tsx/sm" pnpm exec before it, but there are limitations.
For example, the default:

"Build": "Vue tsc && vite build",

I found this to be feasible

"Build": "NODE-OPTIONS=\" -- import tsx/em \ "pnpm exec vite build",

But adding Vue TSC is not enough, what should I do

"Build": "NODE-OPTIONS=\" -- import tsx/sm \ "pnpm exec vue tsc && vite build",

garydex · 2024-05-17T10:58:15Z

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:

Each TS module's tsconfig.json isn't correctly respected. We need to reuse https://github.com/dominikg/tsconfck for that.

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.

@sodatea I'd love to get involved in this. I'm comfortable with using tsconfck and esbuild-register to register tsconfig paths in resolveConfig for the first point, but how would you solve for the second point?

Edit: Turns out it's just as simple as stopping the imports running through the externalize-deps plugin. If there's a tsconfig.json nearby, we can check that an import is in the paths and ignore it.

…5370)

…nfig file (vitejs#5370)

garydex · 2024-05-24T15:46:20Z

Would love someone to take a look at the PR above.

FYI @mandarini I have also created a demo Nx workspace with my patched version of Vite, to demonstrate how a shared config file can be imported and extended - check out https://github.com/garydex/nx-vite-tsconfig-paths

Neo-Ciber94 · 2024-06-10T23:59:36Z

"NODE_OPTIONS='--import tsx' vite ..."

Thanks, that worked for me

juliusfriedman · 2024-06-20T21:14:54Z

/* eslint-disable import/no-relative-packages */ // https://github.com/vitejs/vite/issues/5370
import defaultConfig from './node_modules/@myPackage/vite-config/vite.config';

Where vite.config is /vite.config.ts in the directory of where you want to share it from.

This works around the issue aforementioned and allows you to share the config.

Hopefully it helps someone as it doesn't require any other hacks / changes and keeps the config in TypeScript.

7086cmd · 2024-08-14T01:06:58Z

In my opinion, an alternative effective approach is to pre-bundle the configuration file using Rolldown or Esbuild. Recently, I attempted to execute the command rolldown vite.config.ts -d dist/config -e vite,@vitejs/plugin-react && vite -c dist/config/vite.config.js (Rolldown is not currently available for command-line options), and it starts the dev server, and builds without any issues.

Although it may be somewhat intricate, it could prove to be highly effective for managing complex configurations.

tylerrrkd · 2024-09-13T08:25:44Z

Hi friends, is there any best practice?

…ther packages in the same monorepo (vitejs#5370)

alamhubb · 2024-09-19T16:41:58Z

Try to fix this issue. If the file path contains node_modules, the file will not be compiled. If it does not contain node_modules, it means the local path, so it will be compiled. Is there any unexpected situation? If not, can you merge the PR and close this issue?

#18146

alamhubb · 2024-09-19T18:47:53Z

type must be commonjs

  "type": "commonjs",
  "scripts": {
    "dev": "tsx ./node_modules/vite/bin/vite.js",
    "build": "run-p type-check \"build-only {@}\" --",
    "preview": "vite preview",
    "build-only": "vite build",
    "type-check": "vue-tsc --build --force"
  },

This code works for me

antitoxic · 2024-09-23T15:06:07Z

For the examples above that use a custom loader like tsx, just keep in mind this will inevitably add performance penalty for all imports that vite has inside itself and all your configured plugins. Not just the imports in your config.

jesse23 · 2024-10-02T11:08:16Z

type must be commonjs

  "type": "commonjs",
  "scripts": {
    "dev": "tsx ./node_modules/vite/bin/vite.js",
    "build": "run-p type-check \"build-only {@}\" --",
    "preview": "vite preview",
    "build-only": "vite build",
    "type-check": "vue-tsc --build --force"
  },

This code works for me

Thx for the solution! This works for me.

But it will trigger warning below:

The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

…gs (#1926) - add `sass-embedded` to catalog and use it instead of `sass` - add workspace package `@sit-onyx/shared` for shared configs - add `vite.config.base.ts` file for shared Vite base config - right now we can't use a module import because of an [open Vite issue](vitejs/vite#5370). We have to use a relative import instead.

spacedawwwg · 2024-10-16T19:01:48Z

import { tsImport } from 'tsx/esm/api';
import { defineConfig, mergeConfig } from 'vite';

const { viteConfig } = await tsImport('@mynamespace/configs/vite', import.meta.url);

export default mergeConfig(
  viteConfig,
  defineConfig({
    // custom config here
  }),
);

This is what I'm doing to work around this.

Using: https://tsx.is/dev-api/ts-import

vjpr · 2024-10-16T19:25:01Z

I'm using Bun, and it works great for this use case...except that Bun can crash sometimes.

There is also this issue with Bun: sveltejs/kit#12807

kuus · 2024-10-19T12:12:07Z

import { tsImport } from 'tsx/esm/api';
import { defineConfig, mergeConfig } from 'vite';

const { viteConfig } = await tsImport('@mynamespace/configs/vite', import.meta.url);

export default mergeConfig(
  viteConfig,
  defineConfig({
    // custom config here
  }),
);

This is what I'm doing to work around this.

Using: https://tsx.is/dev-api/ts-import

It does not seem to work with tsconfig paths aliases (I am within an Nx monorepo), you confirm?

zheeeng added the pending triage label Oct 21, 2021

haoqunjiang changed the title ~~Import symlink ts file in vite.config.ts meets resoving problem.~~ vite.config.ts can't import untranspiled ts files from other packages in the same monorepo Oct 21, 2021

haoqunjiang added p2-nice-to-have Not breaking anything but nice to have (priority) and removed pending triage labels Oct 25, 2021

zheeeng closed this as completed Oct 25, 2021

github-actions bot locked and limited conversation to collaborators Nov 9, 2021

vitejs unlocked this conversation Nov 24, 2021

Niputi reopened this Nov 24, 2021

bluwy mentioned this issue Mar 10, 2022

Monorepo support for config imports #3067

Closed

bluwy added the contribution welcome label Mar 28, 2022

This was referenced Jul 15, 2022

fix: externalize workspace relative import when bundle config #9140

Merged

Vite >=3.0.1 fails to resolve projects in monorepo #9202

Closed

stewarthsoj mentioned this issue May 19, 2024

Vite: custom tsconfig paths are not respected when I pass getLoadContext to the Cloudflare Proxy plugin remix-run/remix#9171

Open

garydex added a commit to garydex/vite that referenced this issue May 22, 2024

fix: allow imports from local workspace paths in config file (vitejs#…

9f09edd

…5370)

garydex added a commit to garydex/vite that referenced this issue May 23, 2024

feat(config): allow imports from local workspace tsconfig paths in co…

98bca49

…nfig file (vitejs#5370)

garydex mentioned this issue May 23, 2024

feat(config): allow imports from local workspace tsconfig paths (#5370) #17286

Closed

bluwy mentioned this issue Jun 6, 2024

fix: avoid externalizing plugins that resolve to local files in monorepos #17323

Open

gzdunek mentioned this issue Jul 4, 2024

Export configured Vite plugins from packages/build gravitational/teleport#43847

Merged

stan-dot mentioned this issue Jul 22, 2024

test various vitest setups DiamondLightSource/squid#4

Open

roman-petrov mentioned this issue Aug 14, 2024

fix(sass): replace default import with ESM module import #17880

Closed

alamhubb added a commit to alamhubb/vite.config.ts-support-ts-files-from-other-packages-in-the-same-monorepo that referenced this issue Sep 19, 2024

fix(config): vite.config.ts can't import untranspiled ts files from o…

bd92f60

…ther packages in the same monorepo (vitejs#5370)

alamhubb mentioned this issue Sep 19, 2024

fix(config): vite.config.ts can't import untranspiled ts files from other packages in the same monorepo (#5370) #18146

Open

JoCa96 mentioned this issue Oct 7, 2024

chore: switch to sass-embedded and remedy sass API deprecation warnings SchwarzIT/onyx#1926

Merged

ferferga mentioned this issue Oct 26, 2024

Imported TypeScript files in eslint.config.ts doesn't work eslint/config-inspector#95

Open

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

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

Comments

zheeeng commented Oct 21, 2021 • edited Loading

Describe the bug

Reproduction

System Info

Used Package Manager

Logs

Validations

haoqunjiang commented Oct 25, 2021 • edited Loading

zheeeng commented Oct 25, 2021

zheeeng commented Oct 25, 2021

haoqunjiang commented Oct 25, 2021

haoqunjiang commented Nov 24, 2021 • edited Loading

hiukky commented Mar 10, 2022

github-actions bot commented Mar 28, 2022

julianklumpers commented Apr 7, 2022

airtonix commented Apr 9, 2022 • edited Loading

julianklumpers commented Apr 9, 2022

airtonix commented Apr 11, 2022

black7375 commented May 25, 2022 • edited Loading

bluwy commented Jun 26, 2022

Hobart2967 commented Jul 2, 2022 • edited Loading

jrson83 commented Jul 3, 2022 • edited Loading

Hobart2967 commented Jul 4, 2022

airtonix commented Jul 13, 2022 • edited Loading

btakita commented Jul 24, 2022 • edited Loading

smaven commented May 15, 2024

MQYForverT commented May 16, 2024

smaven commented May 16, 2024

MQYForverT commented May 17, 2024 • edited Loading

garydex commented May 17, 2024 • edited Loading

garydex commented May 24, 2024

Neo-Ciber94 commented Jun 10, 2024

juliusfriedman commented Jun 20, 2024 • edited Loading

7086cmd commented Aug 14, 2024 • edited Loading

tylerrrkd commented Sep 13, 2024

alamhubb commented Sep 19, 2024

alamhubb commented Sep 19, 2024 • edited Loading

antitoxic commented Sep 23, 2024

jesse23 commented Oct 2, 2024

spacedawwwg commented Oct 16, 2024 • edited Loading

vjpr commented Oct 16, 2024 • edited Loading

kuus commented Oct 19, 2024

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

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

zheeeng commented Oct 21, 2021 •

edited

Loading

haoqunjiang commented Oct 25, 2021 •

edited

Loading

haoqunjiang commented Nov 24, 2021 •

edited

Loading

airtonix commented Apr 9, 2022 •

edited

Loading

black7375 commented May 25, 2022 •

edited

Loading

Hobart2967 commented Jul 2, 2022 •

edited

Loading

jrson83 commented Jul 3, 2022 •

edited

Loading

airtonix commented Jul 13, 2022 •

edited

Loading

btakita commented Jul 24, 2022 •

edited

Loading

MQYForverT commented May 17, 2024 •

edited

Loading

garydex commented May 17, 2024 •

edited

Loading

juliusfriedman commented Jun 20, 2024 •

edited

Loading

7086cmd commented Aug 14, 2024 •

edited

Loading

alamhubb commented Sep 19, 2024 •

edited

Loading

spacedawwwg commented Oct 16, 2024 •

edited

Loading

vjpr commented Oct 16, 2024 •

edited

Loading