Comments (10)
Actually it's funny, my traditional means of doing this is nicer in that all aliases are resolved but considering the .d.ts
is a TS file I guess maybe TS's built in aliases should work?
from vite-plugin-dts.
Would you share your vite.config.ts
and tsconfig.ts
files?
I think this requires some testing with other plugins.
from vite-plugin-dts.
Hi @qmhc I was just coming back to this issue as I've confirmed that Microsoft has been asked many times about whether .d.ts
files should follow path aliases (since they are part of the TS spec) but their position is that it should not follow them and I guess there are likely good performance reasons for this stance. That said, it does make this that much more important to solve for.
The ts-patch
approach I've alluded to above does work perfectly when using tsc as the underlying engine for transforms. I use this in dozens of repos for this purpose but unfortunately it doesn't pair well with this plugin at the moment.
I had a look at your deps and i would appear you're passing the DTS generation over to tsup. I think anything from @egoist is worth building around and I've been meaning to use TSUP a lot more rather than rolling my own configuations but I'm not aware of how TSUP works under the hood and how to ensure that tsc's plugin API is enabled properly.
from vite-plugin-dts.
I do wonder if maybe this issue needs to be brought over to TSUP as the actual engine for building the declaration files needs to resolve these path aliases either by some means of it's own or by using the containing repo's instance of tsc (as my instance has been patched to use the Typescript plugin API).
from vite-plugin-dts.
Ok I ran TSUP locally in a repo which doesn't have any Vue components (aka, so the Vue loader isn't needed) and it transpiled perfectly down to a single typed file. However, when I then added this plugin to the same repo it created the types not in a single file but rather in a tree structure which mimics where the types are defined:
and then in the files which utilize the path alias it fails, as you can see in this screenshot:
from vite-plugin-dts.
My configuration files are:
vite.config.ts
import path from "path";
import { defineConfig, UserConfig } from "vite";
import Vue from "@vitejs/plugin-vue";
import WindiCSS from "vite-plugin-windicss";
import Icons from "unplugin-icons/vite";
import IconsResolver from "unplugin-icons/resolver";
import Inspect from "vite-plugin-inspect";
import Components from "unplugin-vue-components/vite";
import PC from "vite-plugin-particle-components";
import dts from "vite-plugin-dts";
export default defineConfig({
resolve: {
dedupe: ["vue"],
alias: {
"~/": `${path.resolve(__dirname, "src")}/`,
},
},
publicDir: false,
build: {
lib: {
name: "particle-components",
entry: path.resolve(__dirname, "src/known-components.ts"),
},
minify: "esbuild",
rollupOptions: {
external: ["vue"],
output: {
globals: {
vue: "Vue",
router: "VueRouter",
},
},
},
},
plugins: [
Vue(),
WindiCSS(),
Components({
resolvers: [IconsResolver()],
dts: true,
extensions: ["vue"],
}),
Icons(),
Inspect(),
dts(),
PC(),
],
} as UserConfig);
tsconfig.json
{
"compilerOptions": {
"module": "es2020",
"target": "es2020",
"lib": ["DOM", "ESNext"],
"strict": true,
"esModuleInterop": true,
"incremental": true,
"skipLibCheck": true,
"moduleResolution": "node",
"resolveJsonModule": true,
"noUnusedLocals": true,
"strictNullChecks": true,
"forceConsistentCasingInFileNames": true,
"baseUrl": ".",
"declaration": true,
"outDir": "dist",
"paths": {
"~/*": ["src/*"]
},
"types": ["vite/client"],
"plugins": [
// Transform paths in output .js files
{ "transform": "typescript-transform-paths" },
// Transform paths for declarations files
{ "transform": "typescript-transform-paths", "afterDeclarations": true }
]
},
"include": ["src"],
"exclude": ["dist", "node_modules", "**/*.spec.ts"]
}
from vite-plugin-dts.
I was digging around in your source code and realized that tsup is used to build this plugin but you aren't wrapping it's capabilities into this plugin. Guess that explains why they behave differently 😝
from vite-plugin-dts.
Thanks for your research first!
This plugin is using ts-morph
(you can find it in package.json -> dependencies
) to create typescript programs and source files, and using typescript LanguageService
to emit output files. Finally it using some regular expressions to further process the .d.ts
files in outputs.
After I did some debugging, I found there is a problem in judging whether a path is alias path when alias find
(is the key when using key-value config) ends with '/'.
Currently a workaround is to change the alias config in vite.config.ts
:
import path from 'path'
import { defineConfig } from 'vite'
export default defineConfig({
resolve: {
alias: {
'~': path.resolve(__dirname, 'src')
}
}
}
from vite-plugin-dts.
@qmhc many thanks for looking into this; i'll use the workaround for now. Any sense for when this will be fixed? No pressure, just aware that my own attention is spread quite thinly and want to keep an eye out for it if its relatively soon.
from vite-plugin-dts.
Great. Many thanks. I did a little reading on ts-morph last night ... looks really useful as my normal experience with AST's has been quite painful.
from vite-plugin-dts.
Related Issues (20)
- Error: ENOTEMPTY: directory not empty, rmdir during rollup HOT 2
- Before .ts analysed hook HOT 4
- Wrong declaration file for union types with null or undefined HOT 2
- 现在源文件以.d.ts结尾的文件没法打包到dist目录中 HOT 2
- Support defineModel in Vue3.4
- The inferred type of 'default' cannot be named without a reference to '.pnpm/[email protected]/node_modules/vue'. This is likely not portable. A type annotation is necessary HOT 1
- Types compiled using alias that doesn't exist in package HOT 1
- Version 3.8.1 doesn't work with path aliases HOT 4
- imports inside module declaration are moved outside, which can break types HOT 1
- Default export missing when using `rollupTypes`
- Support `export * as _` syntax HOT 2
- Duplicate definition of types when multiple entrypoints HOT 4
- Errors being swallowed when `rollupTypes: true` HOT 2
- 【Regression】Library which use IterableIterator.entries() cause TS Error. HOT 2
- 升级 language-tools 到 2.0 HOT 1
- Wrong definition generations since 3.8.2 for
- feat: Add a way to get the TypeScript program instance
- 打包一个库的时候,defineProps问题 HOT 1
- 3.8.0+ Cannot build while excluding vite-env.d.ts
- Invalid imports in generated d.ts for project with tsconfig path alias defined for any module
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vite-plugin-dts.