-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
vite.config.ts
can't import untranspiled ts files from other packages in the same monorepo
#5370
Comments
vite.config.ts
can't import untranspiled ts files from other packages in the same monorepo
Hi, we've discussed this issue at last Friday's team meeting. Considering that:
So this feature would be a low priority for the team. |
Thx for your discussion, I would try to transpile the ts config file. |
@sodatea Can we add an environment variable for configuring this? |
Environment variables are also a kind of configuration, so I don't think we should do that. |
I just realized that we could use a loader like I'm not sure if we can use
Anyway, this is a low-priority but doable feature. |
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. |
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! |
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. Anyway, we ended up writing the base config file in plain js with
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'),
}),
],
});
}); |
use preconstruct on your packages... then you can just sidestep all this headache. it sets up mjs and cjs stubs that behave differently in development than in production. 👍🏻 |
@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. |
🤷🏻 it's not much tbh. compared to the drama llama of your current situation, i'd happily pick preconstruct. |
@airtonix IMO, I think we need a feature like webpack-merge of webpack production doc @julianklumpers
|
Wouldn't using something like I tried a different solution, by bundling the monorepo package when detected that the resolved path doesn't contain Overall I'm also not sure if this is worth the complexity. |
Same issue here. I created 6 package projects within a Lerna workspace. 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 :( |
If you want to use a monorepo/workspace with typescript, you should set it up correctly using project references with compilerOptions 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:
|
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.
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 |
Now that vite 3 is using esm, I'm getting an issue with importing *.ts files in monorepo packages ( 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
Agreed. The problem with partial support for TypeScript is that the support becomes a moving target...such as the |
Using // 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:
vite.config.ts
package.json
but report a error:ReferenceError: __dirname is not defined |
@MQYForverT I think the error is because |
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.
I found this to be feasible
But adding Vue TSC is not enough, what should I do
|
@sodatea I'd love to get involved in this. I'm comfortable with using tsconfck and esbuild-register to register tsconfig paths in 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 |
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 |
Thanks, that worked for me |
Where 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. |
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 Although it may be somewhat intricate, it could prove to be highly effective for managing complex configurations. |
Hi friends, is there any best practice? |
…ther packages in the same monorepo (vitejs#5370)
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? |
For the examples above that use a custom loader like |
Thx for the solution! This works for me. But it will trigger warning below:
|
…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.
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. |
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 |
It does not seem to work with tsconfig |
Describe the bug
If we import something from symlink and the importee is ts file. We counter a such error:
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
Used Package Manager
pnpm
Logs
Validations
The text was updated successfully, but these errors were encountered: