Vue 3.3 causing unresolved types to fail build when using props destructuring with a default value

[kalvenschraut]

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

core/packages/compiler-sfc/src/script/defineProps.ts

Line 314 in a374d7e

if (

needs to check for 'null' instead of UNKNOWN_TYPE.

Unknown TYPE should not exist in the array due to to being set to ['null' ]

core/packages/compiler-sfc/src/script/defineProps.ts

Line 314 in a374d7e

if (

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

[edison1105]

https://github.com/kalvenschraut/vue-unresolved-types-build-failure/blob/master/packages/types/dist/index.d.ts

export { Color } from './Styling.js'; // should be './Styling'

[kalvenschraut]

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.

[edison1105]

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 improve resolveExt logic eg: if the file passed in is not a ts file, remove the file extension then try resolve.

[kalvenschraut]

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]

@kalvenschraut
Vue does not support resolve type elements from an empty js file

[kalvenschraut]

@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

[kalvenschraut]

Updated the repo to show this

[kalvenschraut]

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.

core/packages/compiler-sfc/src/script/resolveType.ts

Line 746 in a374d7e

if (source.startsWith('.')) {

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.