Vue 3.3 causing unresolved types to fail build when using props destructuring with a default value
Vue version
3.3.2
Link to minimal reproduction
https://github.com/kalvenschraut/vue-unresolved-types-build-failure
Steps to reproduce
See README in the repo.
What is expected?
Build to resolve the type in 3.3, or if can not be resolved do not fail build
What is actually happening?
Type is inferred to be ['null']
which is not the UNKNOWN_TYPE
so causes the build to fail.
I think https://github.com/vuejs/core/blob/a374d7e6ed973cde7fae36ee82618cf46a8ba68a/packages/compiler-sfc/src/script/defineProps.ts#L314
needs to check for 'null'
instead of UNKNOWN_TYPE
.
Unknown TYPE should not exist in the array due to to being set to ['null' ]
https://github.com/vuejs/core/blob/a374d7e6ed973cde7fae36ee82618cf46a8ba68a/packages/compiler-sfc/src/script/defineProps.ts#L314
Also I would expect my type to be resolved, but that could be considered a separate issue I can open with the same reproduction if it needs to be.
System Info
System:
OS: Linux 5.15 Gentoo Linux
CPU: (4) x64 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
Memory: 19.12 GB / 26.78 GB
Container: Yes
Shell: 5.1.16 - /bin/bash
Binaries:
Node: 18.12.1 - /usr/bin/node
Yarn: 3.3.0 - /usr/bin/yarn
npm: 8.19.2 - /usr/bin/npm
Watchman: 2023.01.16.00 - /usr/bin/watchman
Browsers:
Firefox: 102.7.0esr
npmPackages:
vue: 3.3.2 => 3.3.2
Any additional comments?
No response
export { Color } from './Styling.js'; // should be './Styling'
I don't think it should matter about the extension TBH. Volar resolves to the file correctly when using go to definition.
Also regardless Vue should not be failing to build if the type cannot be resolved.
Also regardless Vue should not be failing to build if the type cannot be resolved.
Agreed.
I'm not sure if this is a bug
- maybe we should avoid hard errors when the inferredType does not match the declared type.
export { Color } from './Styling.js'
. maybe we can improveresolveExt
logic eg: if the file passed in is not a ts file, remove the file extension then try resolve.
The inferred type here is null (based on my comments in the original post) which is to represent an any type from what I recall in the docs, meaning the declared type should be matching it in this case.
Also I do believe it is standard to have the .js extension if the module resolution is nodenext. Granted volar seems to recommend moving to bundler module resolution which is new in typescript 5.0. https://www.typescriptlang.org/docs/handbook/esm-node.html
Not to mention the .d.ts can have a ts extension if allowImportingTsExtensions
is in the tsconfig which is what I would be moving to when I switch to module resolution bundle. Which also has this same problem.
@edison1105 That doesn't change the problem. It didn't seem to affect the error so I didn't add any value to the ts file
I would say the problem is more so that vue is trying to do a relative resolve of an import that is inside of an external package.
While this could work, would have to fix resolveExt
to handle the various scenarios, I think the more ideal direction is to allow typescript resolve these relative imports if there are not within your own package here.
https://github.com/vuejs/core/blob/a374d7e6ed973cde7fae36ee82618cf46a8ba68a/packages/compiler-sfc/src/script/resolveType.ts#L746
Not sure how feasible that direction is. Only thing I can think of it having to know where the project root is and compare the source.filename with that before determining your direction. Maybe by using process.cwd()?
Otherwise, I would just strip off any extension and try the various ones it already is doing. The .js extension will resolve to the actual built file without the types which would be bad. If allow .ts extension still needs to be stripped since likely looking for .d.ts if its inside an external package due to the files likely being built by some tool.