Typescript is not recognized well

[cesxhin]

I updated to version 1.0.1 and I'm having a problem recognizing the typescript structure of the components.

For example now in my project in the file: ".nuxt/components.d.ts"
there is a component of the module that I made but it tells me any.

Instead I have another library (also made by me) and it recognizes very well and I have not updated module-builder.

UPDATED

If I specify .d.ts in the ".nuxt/components.d.ts" file instead, it works.

export const FormFields: typeof import("../node_modules/@xxxxxx/fields-loader/dist/runtime/components/formFields.vue.d.ts")['default']

Current settings package.json:

[...]
"exports": {
    ".": {
      "types": "./dist/types.d.mts",
      "import": "./dist/module.mjs"
    },
    "./components/*": "./dist/runtime/components/*",
    "./utils/*": "./dist/runtime/utils/*"
  },
  "main": "./dist/module.mjs",
  "typesVersions": {
    "*": {
      ".": [
        "./dist/types.d.mts"
      ],
      "components/*": [
        "./dist/runtime/components/*.d.ts"
      ],
      "utils/*": [
        "./dist/runtime/utils/*.d.ts"
      ]
    }
  },
  "files": [
    "dist"
  ],
[...]

[quantix-dev]

I tried making a minimal reproduction and this seems to work for me (no type errors).
https://stackblitz.com/edit/nuxt-module-builder-x983ks

Instead I have another library (also made by me) and it recognizes very well and I have not updated module-builder.

I'm using file modules in the playground to replicate your environment,
It seems to be working fine.

It is important to note you can't do .default on a type in TypeScript. It must be indexed with square brackets ['default']
https://www.typescriptlang.org/docs/handbook/2/indexed-access-types.html

[danielroe]

Would you be able to provide a reproduction? 🙏

[github-actions]

We cannot recreate the issue with the provided information. Please add a reproduction in order for us to be able to investigate.

Why was this issue marked with the needs-reproduction label?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. Please provide a link to either :

• a public GitHub repository
• a CodeSandbox
• a StackBlitz.

To make sure the issue is resolved as quickly as possible, please make sure that the reproduction is as minimal as possible. This means that you should remove unnecessary code, files, and dependencies that do not contribute to the issue.

I added a link, why was it still marked?

Ensure the link is pointing to a codebase that is accessible (e.g. not a private repository). "example.com", "n/a", "will add later", etc. are not acceptable links -- we need to see a public codebase. See the above section for accepted links.

What happens if I don't provide a sufficient minimal reproduction?

Issues with the needs-reproduction label that receives no meaningful activity (e.g. new comments with a reproduction link) will be closed by the maintainers and won't be looked at.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using a reaction on the topmost comment.

• Please do not comment "I have the same issue" without repro steps
• Please do not comment un-helpful messages such as "+1" on an issue, use reactions on the first comment instead.

I think my reproduction is good enough, why aren't you looking into it quicker?

We constantly monitor open issues for new comments.

However, sometimes we might miss one or two. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible.

I have a minimal reproduction to contribute to a closed issue.

If you have a minimal reproduction for a closed issue, please write a comment on the issue with a link to the reproduction.
We will review it and reopen the issue if it is sufficient.

Useful Resources

• Why reproductions are required
• How to create a Minimal, Complete, and Verifiable example

[hanneskuettner]

Seems like this problem is also plaguing the most recent NuxtUI 3.1.0 release, see nuxt/ui#3973 for the corresponding NuxtUI issue and this code sandbox as a reproduction https://codesandbox.io/p/devbox/flamboyant-scott-k7p4kv. In the sandbox I try to import the ButtonProps from NuxtUI.

In a previous version of NuxtUI build with @nuxt/module-builder 0.8.4 the same import works, see https://codesandbox.io/p/devbox/gracious-https-84vh6c

[danielroe]

I can't access that link.

[hanneskuettner]

I can't access that link.

Whoops. Mind giving it a second try? Was still on private by default.

[hanneskuettner]

Here is another Stackblitz reproduction with the same setup: Nuxt starter Stackblitz + NuxtUI built with @nuxt/[email protected]: https://stackblitz.com/edit/github-hdv1fzks?file=package.json,app.vue

[danielroe]

Can you reproduce without Nuxt UI?

(The issue might be to do with nuxt/ui rather than the module builder.)

https://arethetypeswrong.github.io/?p=%40nuxt%2Fui%403.1.1

[danielroe]

@hanneskuettner @benjamincanac looks like there's an issue with pkg-pr-new generated files (or, if this is the only version with the latest module-builder, an issue with the build config or module builder):

e.g. https://pkg.pr.new/@nuxt/ui@df83ab3 has this in @nuxt/ui/.nuxt/ui/progress.ts:

import template from "/home/runner/work/ui/ui/src/theme/textarea"

const buttonGroup = [
  "horizontal",
  "vertical"
] as const

this is unresolvable of course (cc: @benjamincanac)

however, resolving that issue we still have somewhat of a problem - seems like Vue can't resolve types exported from SFCs. Here's a reproduction with just Vue + Nuxt:

https://stackblitz.com/edit/github-tapjwz4t?file=packages%2Fexample%2Fpackage.json%2Cpackages%2Fexample%2Fmodule.mjs%2Cpackages%2Fexample%2Fmodule.d.mts%2Cpackages%2Fexample%2FComponent.vue%2Cpackages%2Fexample%2FComponent.vue.d.ts%2Capp.vue%2Cpackage.json%2Cnuxt.config.ts

I'll need to see if we can reproduce with Vite + Vue (without Nuxt).

[benjamincanac]

@danielroe This was a bug introduced in 3.1.0 but has been fixed already in 3.1.1!

[danielroe]

update: this is reproducible without Nuxt

https://stackblitz.com/edit/github-ja4alwiy

question: is this a bug in @vue/compiler-sfc or are we doing this wrong?

(I wasn't able to get this to work with component.d.vue.ts + allowArbitraryExtensions either, as suggested in unjs/mkdist#270.)

[hanneskuettner]

Don't know if this is somewhat redundant with what you reported @danielroe, but it looks like attempting the same thing with the vite vue-ts starter, even without the additional local package redirection, does not work either.

https://stackblitz.com/edit/vitejs-vite-gq1pwszz

[sandros94]

update: this is reproducible without Nuxt

https://stackblitz.com/edit/github-ja4alwiy

question: is this a bug in @vue/compiler-sfc or are we doing this wrong?

(I wasn't able to get this to work with component.d.vue.ts + allowArbitraryExtensions either, as suggested in unjs/mkdist#270.)

I've just noticed this issue, and while debugging stuff around with vue-tsc the problem is indeed with import { PropsFromComponentExport } from 'example-package';, and the export * from './Component.vue'; part.

The only way I've managed it to make it work is by changing Component.vue.d.ts to Component.d.vue.mts and in module.d.mts:

-export * from './Component.vue';
+export * from './Component.d.vue.mts';

which I don't really like, since typescript's allowArbitraryExtensions should take care of that, but at least it does work.

tagging @cjpearson and @Teages to inform on the topic

EDIT: vue-tsc typechecking does work, so this might be possible by fixing only mkdist itself

[Teages]

I think it is more like a upstream bug, typescript with allowArbitraryExtensions enabled can find the type from Component.d.vue.ts but Vue still can't resolve even it was re-export by a .ts file.

I will try to make a reproduce with @vue/compiler-sfc

[hanneskuettner]

I will try to make a reproduce with @vue/compiler-sfc

Check my stackblitz from above. Afaict this is a reproduction with just @vue/compiler-sfc

https://stackblitz.com/edit/vitejs-vite-gq1pwszz

It has both the .vue.d.ts and .d.vue.ts typing files and allowArbitraryExtensions enabled for testing purposes.

[Teages]

Check my stackblitz from above. Afaict this is a reproduction with just @vue/compiler-sfc

I think it is a reproduction with @vitejs/plugin-vue, did you put the right link?

I want to check what happened when vue resolving the type with extractRuntimeProps

[hanneskuettner]

I think it is a reproduction with @vitejs/plugin-vue, did you put the right link?

Oh sorry! I misunderstood you there. This is obviously using @vue/compiler-sfc under the hood, but not directly.

You can just see it failing with an error from within @vue/compiler-sfc

[danielroe]

I think we need to update in mkdist (and also in vue-sfc-transformer) to export/import from .vue.js:

helpful info from @brc-dd, who writes:

---

I can only get this to work

• if there is Component.vue + Component.vue.d.ts:

// dts
export { default as Component } from './Component.vue.js'
export type * from './Component.vue.d.ts'

// js
export { default as Component } from './Component.vue'

• if there is no Component.vue.d.ts:

// dts
export { default as Component } from './Component.vue'
export type * from './Component.vue' // maybe not needed? since if it was using lang="ts"
                                     // you would've extracted types to dts

// js
export { default as Component } from './Component.vue'

tried other combinations, but they don't appear to be working
IIUC you want to have similar output in both cases, regardless of whether there is Component.vue.d.ts, which I don't think is possible currently 👀

[Teages]

Vue only loads the original .vue file when resolving types.

@vue/compiler-sfc: src/script/resolveType.ts#L1154

I think it would be better to make a patch on vue (don't use original .vue file if .d.vue.ts exists), so that vue can also have allowArbitraryExtensions support.

I'm now starting to wonder if I misunderstood .vue.d.ts in the first place, maybe it is only designed for .vue.js

[sandros94]

Noticed the upstream merge and was checking out https://pkg.pr.new/vue@f7ce5ae (on Daniel's stackblitz with Component.d.vue.ts), now @vue/compiuler-sfc is working correctly.

Typescript still complains for .vue imports (even with allowArbitraryExtensions: true), as well as vue-tsc isn't aware of the .d.vue.ts file

[Teages]

Yes, I'm currently considering solutions.

Previously Vue provided type support for .vue files by making TypeScript recognize the existence of .vue.ts files through configuration workarounds.

I'm concerned that this change might force users to choose between the new .d.vue.ts type definitions and the legacy .vue.d.ts approach.

Maybe we can generate both.