Many peerDependencies are not installed

[IlCallo]

Describe the bug
Most peerDependencies are not explicitly added to the package.json, generating warnings at every yarn add, install, remove, etc.
Quasar works anyway thanks to dependencies de-duplication, but the moment another dependency require a different version of a peerDependency (or one of them is dropped, while the user was relying on its implicit presence), something will fail without a meaningful error message.

@nothingismagick

https://nodejs.org/es/blog/npm/peer-dependencies/

Expected behavior
Quasar and it's extensions should explicitly state their peerDependencies and quasar-cli should automatically add them to package.json (and consequentially install them) upon project creation and extension adding.

Additional context
I made up this partial list based on my memory of last days of trial and error and common sense, but only maintainers really know which should be a peerDependency and which doesn't, so only take it as an hint.

Quasar

• vue
• @babel/core
• webpack
• vue-template-compiler

Every Quasar extension

• @quasar/app

Typescript extension

• typescript
• @typescript-eslint/eslint-plugin (linting based on ESLint)
• @typescript-eslint/parser (linting based on ESLint)
• eslint-config-prettier (linting based on ESLint and Prettier)
• tslint (linting based on TSLint)

Jest testing

• jest

[rstoenescu]

Hi,

Why is this a Quasar bug? Unfortunately, it's an npm architectural decision that is currently outdated. Many other CLIs are in the same bucket as we are. Instead of raising an issue on Quasar, the best approach would be to do it on npm and yarn. They should look at the real dependency tree and not only in package.json.

Quasar is supplying vue and webpack and other packages that are pinned to a specific version. And so they should be. We test them before doing a CLI release so you, the developers won't have to. Everything just works out of the box for you. Not sure if you saw the Vue 2.3 or Vue 2.6 that initially have introduced some problems, or one of the previous Webpack versions (can't remember which, but it broke HMR). Part of our job is to supply you with the latest and greatest AND safe packages that you can use. We could make the CLI install these dependencies BUT we would also need to check them each time a command is run. And it would mean that the CLI perf would go down due to the additional complexity that we would add (not to mention the billion cases that we would need to handle -- for all OSes, for npm, for yarn, only after you have run an yarn/npm install, etc etc, you get the picture). We don't want perf to go down. Instead, why not handle this the proper way, which is to push on npm and yarn maintainers to actually check the installed packages rather than blindly relying on reading package.json. I hope you can agree.

[IlCallo]

Well, I was discussing this two days ago with @nothingismagick on Discord (that's why I referenced him) and he asked me to open the issue here, I didn't know it was a deliberate decision.

Futhermore, "hiding" all stuff behind Quasar seems like fencing off developers from all the other parts of the ecosystem.
It obviously provides advantages, as you explained, but also disadvantages, especially for an open source project.

Checking if quasar works in real-world projects, with newer versions of a particular dependency, becomes more difficult from possible contributors.
With peerDependencies it's as simple as changing a version number in the contributor project well know package.json and testing can start, with related issues filing and solution suggestions, which usually means less work for you and more on the shoulders of the community.
Without them, correct me if I'm wrong, you have to clone quasar repository, get to know the codebase (and it's not so simple for complex systems as Quasar is), change the version, build Quasar distribution, locally link the newly created package and only at this point someone can start testing. Way too much hassle for someone to go throught just to volunteer.

Another point is that, package.json is for humans too: by glancing at it, you can gain a lot of insight about which technologies are being used into a project and why.

Angular for example, which pretty much abuse peerDependencies for all its packages, decided to build an automatic upgrade mechanism into their Angular CLI (ng upgrade), but keeping every dependency exposed.

Also Vue CLI adds some dependencies directly on the project (core.js, typescript, babel-core, etc).

Not saying using peerDependencies is right and you are wrong: of course you know it better than me, having created the framework.
I'm just interested into documenting possible implications for the ecosystem you created, both pros and cons, of the choice.

No problem if you don't have time to deal with this kind of discussions right now ☮️

EDIT: I saw that Vue too is moving torwards a vue-cli upgrade feature like Angular already did.