quasar.conf - support ESM or .cjs config files in module projects

[josh-hemphill]

Is your feature request related to a problem? Please describe.
When people use module type projects, it results in confusing issues like #9454

Describe the solution you'd like
Ideally, it would support loading ESM config files, or maybe even TS

Describe alternatives you've considered
Converting project to classic type, or maybe manually playing around with ts-node or some kind of compilation?

Additional context
Add any other context or screenshots about the feature request here.

[IlCallo]

Here (#6476) there was a previous attempt to support ESM codebases, but I did it when ESM wasn't fully enabled into Node.
We could probably take another look at this in the future, now that we bumped the minimum Node version for @quasar/app to a version supporting ESM natively without flags

[therealcoder1337]

i would also love to see this ("type": "module" in package.json), since there are multiple benefits:

• some coding style in vue code as in quasar config files
• much easier testing, you can probably even drop babel (for testing) if you use esm modules
• future proof / better support for modern packages, since commonjs (require) gets less and less used nowadays, compared to esm (import)

but i imagine it's a lot of work because you would have to rewrite the whole source code.

[hawkeye64]

This will likely come with the Vite support that @rstoenescu is working on. When creating a new project, you will be asked if you want Webpack or Vite.

[IlCallo]

I'd also note that many upsteam projects are forcing the ecosystem by pushing Pure ESM packages

Due to this, it may be an idea to skip from Node 12 to Node 16 directly, we should check which are the main differences

[clintfoster]

I'm wondering if any more thought has been given to this issue? I'm on Node 16 (LTS) and using Vite per https://quasar.dev/quasar-cli-vite/convert-to-quasar-cli-with-vite.

This has been working well for several weeks. I'm happy to be rid of Webpack, Babel, etc. It didn't occur to me to also switch to ESM module resolution until I recently added type: module to 2 other (non-Quasar) projects that I was able to get working with changes like the following:

• Update eslint config to flag any "directory" imports.
• Change all imports to explicitly specify filenames & extensions, e.g. index.js.
• Deal with CommonJS config files, e.g. convert .eslintrc.js to .eslintrc.yml.
• Update Jest, e.g. add useESM: true to jest.config.cjs.

I made the same changes to my Quasar project, and although lint is happy, I get the following error when I run quasar dev:

./node_modules/@quasar/app-vite/lib/quasar-config-file.js not supported.
quasar.config.js is treated as an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which declares all .js files in that package scope as ES modules.
Instead rename quasar.config.js to end in .cjs, change the requiring code to use dynamic import() which is available in all CommonJS modules, or change "type": "module" to "type": "commonjs" in ./package.json to treat all .js files as CommonJS (using .mjs for all ES modules instead).

    at QuasarConfFile.read (./node_modules/@quasar/app-vite/lib/quasar-config-file.js:204:30)
    at goLive (./node_modules/@quasar/app-vite/lib/cmd/dev.js:142:43) {
  code: 'ERR_REQUIRE_ESM'

I tried changing the filename to quasar.config.cjs, with the following result (presumably because it isn't finding the configuration file):

Error Unknown command "dev"

[IlCallo]

Not yet, even Node 16 have many quirks around ESM support unluckily.
We'll fix this in Quasar v3 for sure, but we cannot assure we'll be able to squeeze it in Quasar v2 lifecycle and can't give any ETA about it

[clintfoster]

Thanks for the quick response. Probably it is naive of me to think a quick solution such as the dynamic loader explicitly looking for quasar.config.cjs (or supporting yaml format, as eslint does) would allow Quasar projects to use ESM module resolution. No doubt it is just a superficial symptom since the configuration file is the first thing that's loaded.

[jrgleason]

What is the timeline for Quasar 3? This is a big issue for us as we had to struggle with the same issues with tailwind so this was something we were looking to avoid in Quasar.

Thank you guys very much for all of your work.

[IlCallo]

@clintfoster there are many things to consider, eg a project using native ESM modules from Node (and we use Node in some parts of the framework) must import everything with fully specified path. The Node Loader API is still under heavy development by Node side and experimental

We may be able to make it work right now, but the vast majority of the ecosystem isn't ready yet, so it could bring many headaches with little benefit

I'll leave here some links I found around, since I bumped my head against this topic again today:

• https://2ality.com/2021/06/typescript-esm-nodejs.html#visual-studio-code
• https://nodejs.org/docs/latest-v18.x/api/all.html#all_esm_loaders
• https://github.com/nodejs/loaders-test/tree/main/commonjs-extension-resolution-loader
• https://github.com/esbuild-kit/esm-loader

[IlCallo]

@jrgleason we planned to start working on it this quarter, but Vue 2.7 release could potentially result in a longer lifecycle for Qv1 and thus postponing Qv3 works, as we don't have enough bandwidth to maintain 3 major version of the framework at the same time

Right now we're spending our energies to enhance Qv2 as much as possible instead of planning for Qv3

[ZerdoX-x]

I can't imagine quasar still forces to use commonjs

Can be fixed via #15756

[IlCallo]

Quasar CLI packages (both vite and webpack) are currently being rewritten in ESM
The rewrite will allow using quasar.config with ESM and TS too

[ZerdoX-x]

That quick fix in PR above can allow usage of quasar in ESM project if you put config in cjs file. I hope it will be reviewed properly. IMO it's an important issue which can be easily fixed without waiting for quasar 3 or the whole project being rewritten.

[rstoenescu]

Posting my comment from the PR:

This has already been worked on for next q/app major versions (which will also support everything in ESM format, including the quasar config file).

However, adding this to the current q/apps will be nice as well. BUT, I need to release the new global Quasar CLI first, otherwise commands through it will still fail to recognize the folder as being a Quasar project.

So you will need to be a little patient until I can release the new q/cli.

[tachibana-shin]

It looks like it will be quite a while until a release that supports quasar.config ESM/TS comes out. For those who can't wait this will be a temporary solution for them to be able to use quasar.config.ts (or .cjs, .mjs depending on need) until the release new release:
https://gist.github.com/tachibana-shin/284839d678a3c4be709188dc4b14b6df

[Tofandel]

Any news regarding the ESM/TS quasar config? I'm using vite 5 and the next major of vite will remove CJS support

When building this warning pops up
The CJS build of Vite's Node API is deprecated. See https://vitejs.dev/guide/troubleshooting.html#vite-cjs-node-api-deprecated for more details.

[IlCallo]

The next major version, currently in alpha phase as we finish the upgrade docs, natively supports ESM and TS

[yusufkandemir]

@quasar/app-vite v2 and @quasar/app-webpack v4 is on beta, which have this feature. See the release notes and upgrade guides:

https://github.com/quasarframework/quasar/releases/tag/%40quasar%2Fapp-vite-v2.0.0-beta.1
https://quasar.dev/quasar-cli-vite/upgrade-guide#quasar-app-vite-v2-beta-

https://github.com/quasarframework/quasar/releases/tag/%40quasar%2Fapp-webpack-v4.0.0-beta.1
https://quasar.dev/quasar-cli-webpack/upgrade-guide#quasar-app-webpack-v4-beta-

[MartinX3]

@yusufkandemir would it make sense to change the default module to a newer value (NodeNext) in

quasar/app-vite/tsconfig-preset.json

Line 6 in 9aa98a8

"module": "esnext",

Also we should set "verbatimModuleSyntax": true and with NodeNext we can remove

• "moduleResolution"
• "esModuleInterop"
• "target"
  See https://www.typescriptlang.org/docs/handbook/modules/guides/choosing-compiler-options.html

And according to https://www.typescriptlang.org/tsconfig#moduleResolution our used value node is also deprecated and got replaced by node10 in the official tsconfig to show that it's old.