Since updating to Quasar 2.16.0 functions returning the any type.

[rstoenescu]

Discussed in #17170

^{Originally posted by MartinX3 May 6, 2024}
I updated to Quasar 2.16.0 and @quasar/app-vite 2.0.0-beta.12.
Now eslint errors out because as example this variable has now the type any.

import { date, } from 'quasar'
const daysInMonth = date.daysInMonth(new Date())

I look at the code in my IDE and also hover over the function.
It says the return type is number.
But eslint says any.
Adding the variable type via my IDE also puts the any at it.

And updating app-vite to beta 12 errors out with

Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import '/home/runner/work/[...]/node_modules/quasar/wrappers' is not supported resolving ES modules imported from /home/runner/work/[...]/quasar.config.ts.temporary.compiled.1715059034987.mjs
Did you mean to import "quasar/wrappers/index.js"?
```</div>

[rstoenescu]

Fixed in Quasar v2.16.1

[rstoenescu]

@MartinX3 and @UkonnRa pls try with v2.16.1
Also, make sure that you restart your IDE to eliminate any sync issues.

[UkonnRa]

Impressive! Everything works as expected in 2.16.1! Thanks for your quick support!!!

[MartinX3]

@rstoenescu
Thank you.
quasar dev is fixed but quasar build is (now) broken.

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/home/runner/work/[...]/[...]/node_modules/.pnpm/@[email protected]_@[email protected][email protected]_@[email protected][email protected]_fxwfyg26cdo6pyzenxcq254jcq/node_modules/quasar/dist/transforms/import-transformation.js' imported from /home/runner/work/[...]/[...]/node_modules/.pnpm/@[email protected]_@[email protected][email protected]_@[email protected][email protected]_fxwfyg26cdo6pyzenxcq254jcq/node_modules/@quasar/vite-plugin/src/vue-transform.js
    at finalizeResolution (node:internal/modules/esm/resolve:265:11)
    at moduleResolve (node:internal/modules/esm/resolve:933:10)
    at defaultResolve (node:internal/modules/esm/resolve:1157:11)
    at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:390:12)
    at ModuleLoader.resolve (node:internal/modules/esm/loader:359:25)
    at ModuleLoader.getModuleJob (node:internal/modules/esm/loader:2[34](https://github.com/[...]]/[...]/actions/runs/8982482311/job/24670183936#step:7:35):38)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:87:39)
    at link (node:internal/modules/esm/module_job:86:[36](https://github.com/[...]/[...]/actions/runs/[...]/job/[...]#step:7:37)) {
  code: 'ERR_MODULE_NOT_FOUND',
  url: 'file:///home/runner/work/[...]/[...]/node_modules/.pnpm/@[email protected]_@[email protected][email protected]_@[email protected][email protected]_fxwfyg26cdo6pyzenxcq254jcq/node_modules/quasar/dist/transforms/import-transformation.js'
}

[rstoenescu]

Reinstall from scratch pls. Seems like it's already got the old version of q/vite-plugin and not checking for the newer one.

[MartinX3]

I already removed the node_modules and my pnpm-lock-yaml.
And also my github CI has this problem, too, which doesn't cache the node_modules.
I use 2.16.1 and app-vite beta 12.

[cirolosapio]

I can confirm that the issue is resolved by testing it with both the dev and build commands

[MartinX3]

This is weird.
I removed the node_modules and pnpm-lock-yaml a second time in this 5 minutes and now @quasar/[email protected] added the '@quasar/vite-plugin': 1.7.0 dependency.
Black magic or so.
It works now.

[rstoenescu]

I'll enforce q/app-vite beta to install the newer q/vite-plugin (though it should by default). But working on improving some other stuff before making a new release.

[rstoenescu]

Thanks everyone for your feedback!

[MartinX3]

@rstoenescu
Thank you.
By the way speaking about modules.
Why is quasar using moduleResolution: node with module: esnext in the tsconfig?
According to https://www.typescriptlang.org/tsconfig/#moduleResolution the node value is a deprecated value which got renamed to node10.
The newer ones are node16 / nodenext and the compatibility value bundler.
(module also got the newer value node16 / nodenext)

Node 10 is EOL since 2021-04-01 and Node 16 since 2023-09-11.

Since quasar 2.16 got its package internal build system to ESM it might be useful to refactor the tsconfig-preset in app-vite.

[rstoenescu]

@yusufkandemir pls check the above comment from Martin

[MartinX3]

Thank you.
I remember now I did mark him in march, too.
#9455 (comment)

[panmenghan]

@rstoenescu
v2.16.1 still have a problem: not able to import useQuasar and QuasarPluginOptions

[rstoenescu]

@panmenghan can u show me the output of quasar info pls?

[rstoenescu]

And a reproduction repo would be nice

[panmenghan]

@rstoenescu
https://github.com/panmenghan/quasar-bug

Install with pnpm i

Open index.ts with vscode, and the error will show

[rstoenescu]

@panmenghan
Seems an issue with your tsconfig.json. Changing the following works:

"module": "esnext",
"moduleResolution": "node",

[MartinX3]

Better to use

"moduleResolution": "Bundler",
"verbatimModuleSyntax": true

node alias node10 is really outdated.
The modern moduleResolution are node16 nodenext bundler

In my case I also use the modern "type": "module", in my package.json and

"module": "esnext",
"moduleResolution": "node",

leads to as example Cannot find module '@yeger/vue-masonry-wall' or its corresponding type declarations. with the vue-tsc checker.
bundle as above fixed it for me.

[panmenghan]

@MartinX3 @rstoenescu
Thanks.

Change the value of moduleResolution to Bundler or node both works.

But if quasar support all the moduleResolution mode would be better.

The node16 mode require all the relative import(dist/types/*.d.ts) explicitly add .js extension and imported folder with /index.js suffix. But if the Bundler or node mode, the .js or ./index.js can be omited.

[rstoenescu]

We'll improve this in the near future. Right now I just wanted to give a hint on where the problem is coming from. Did not mean that module + moduleResolution should only have that values.

[IlCallo]

@panmenghan

But if quasar support all the moduleResolution mode would be better.

Are we talking about Quasar UI package or Quasar CLIs here?
Cause Quasar CLIs are meant to work with the related bundler, so this sentence may not make sense

I can't access the repro you provided, so I can't tell if the problem you highlighted was with Quasar CLIs or Quasar UI

@MartinX3 I've checked your proposal to change the tsconfig preset as written here

module to nodenext

This doesn't really make sense, an app generated with Quasar is meant to run in the browser, not in Node
Even when running in SSR mode, it's the bundler which manages the compilation, not TS itself
Thus, it should remain set to esnext

Sources:

• first paragraph of module documentation: "You very likely want "nodenext" for modern Node.js projects and preserve or esnext for code that will be bundled."
• the guide to tsconfig that you linked, in the "app with bundler" section

moduleResolution

We definitely need to update this to bundler value

Sources:

• https://www.typescriptlang.org/tsconfig/#moduleResolution

Add verbatimModuleSyntax

I'm still unsure about this, but its usage doesn't seem to bring any real benefit in our use case, from what I can understand
Again: we're using a bundler, while verbatimModuleSyntax is meant to simplify how TS decides what to elide and what not
In our case, we probably want to rely on the bundler own tree-shaking mechanism and on TS own capabilities of detecting what is a type and what not
I think that in our case this option is irrelevant at best, possibly confusing and causing headaches at worst, so I'd avoid it

Also, enabling it doesn't mean we can drop esModuleInterop nor target

Sources:

• https://www.typescriptlang.org/tsconfig/#verbatimModuleSyntax

Add allowArbitraryExtensions

You didn't suggest this, but I found it out in the same guide, so I checked it out
It doesn't seems something we need to enable right now, so I'd leave it disabled until we get a valid use case for it

---

Quasar UI tsconfig is another topic, only partially related to tsconfig-preset served by Quasar CLIs
Quasar UI is actually a JS project which is then transpiled using esbuild IIRC

The tsconfig is mostly there to allow for types authoring and to prepare for the codebase TS migration, when we'll have time to spend on that

I don't think tsconfig.json into Quasar UI is actually used for anything else, except validating the generated types, and it shouldn't cause any kind of errors wherever you decide to use it

[IlCallo]

Addendum to my comment about Quasar UI tsconfig which confirms my point from TS handbook

Of course, this guidance can only apply in cases where the library ships outputs from tsc. If the library is being bundled before shipping, "moduleResolution": "bundler" may be acceptable. Any build tool that changes the module format or module specifiers to produce the final build of the library bears the responsibility of ensuring the safety and compatibility of the product’s module code, and tsc can no longer contribute to that task, since it can’t know what module code will exist at runtime.

If we used tsc to generate the dist bundles for Quasar UI, the correct option for module and moduleResolutions would be nodenext, and we may decide to change that just to stop using the deprecated node option for moduleResolutions, but Quasar UI package dist files are generated via a build process which doesn't actually involve tsc, so the tsconfig.json change shouldn't affect downstream users in any way

[MartinX3]

@IlCallo
Thank you for your answer.

In my case I use a tsconfig.json with the following content:

{
  "extends": "@quasar/app-vite/tsconfig-preset",
  "compilerOptions": {
    "baseUrl": ".",
    "moduleResolution": "Bundler",
    "verbatimModuleSyntax": true
  },
  "exclude": ["./dist", "./.quasar", "./node_modules", "./src-capacitor", "./src-cordova", "./quasar.config.*.temporary.compiled*"]
}

And the tsconfig.vue-tsc.json:

{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "skipLibCheck": true
  }
}

In my package.json I use:
"type": "module",

The project then gets compiled into a static page for access via a http server without node.

I needed to switch to exactly these settings to avoid any error in the dev mode (node) or static mode on the webserver with some dependencies.
Like as example Cannot find module '@yeger/vue-masonry-wall' or its corresponding type declarations. from vue-tsc in dev mode.

So at the moment using these additional settings everything just runs fine.