Split this library so we are not forced to install dependencies we do not need.

[Izhaki]

Is your feature request related to a problem? Please describe.

Improvement.

Our workflow involves typechecking in development builds (watch), but linting, formatting, and other checks are done in either pre-commit hook, or CI (also on the IDE).

We would like to use this package, but it brings a host of dependencies, most of them we don't use (and those can conflict with the versions we will already have).

From package.json:

  },
  "peerDependencies": {
    "eslint": ">=7",
    "meow": "^9.0.0",
    "stylelint": ">=13",
    "typescript": "*",
    "vite": ">=2.0.0",
    "vls": "*",
    "vti": "*",
    "vue-tsc": "*",
    "optionator": "^0.9.1"
  },

Describe the solution you'd like

The ability to only use and install what is actually being used. One way to do this is to split this package into its constitutes, possibly with some core or common package.

Describe alternatives you've considered

This is a design issue.

Additional context

No response

Validations

• [X] Read the docs.
• [X] Read the Contributing Guidelines.
• [X] Check that there isn't already an issue that asks for the same feature to avoid creating a duplicate.

[fi3ework]

The dependencies you listed above are peerDependencies but they also are optional which means you only need to install what checker deps you need. Even though we split the packages into such @vite-plugin-checker/core and @vite-plugin-checker/eslint, the core checker dependencies which is ESLint is still inevitable to be installed by the user. The relationship between vite-plugin-checker and ESLint is like antd and react.

https://github.com/fi3ework/vite-plugin-checker/blob/f65aa71a1ac9ab8374085449503174be935658c6/packages/vite-plugin-checker/package.json#L61-L97

[Izhaki]

Peer Dependencies

As explained here:

Some way of saying, "I only work when plugged in to version 1.2.x of my host package, so if you install me, be sure that it's alongside a compatible host." We call this relationship a peer dependency.

A classic example is a React UI library (like MUI) - it will mark React as a peer dependency as if to say:

"I need this to work, but surely you have it already, so I'm just letting you know which versions I work with".

True, yarn and npm don't install them, but they do complain about unmet requirements. So if, as in our case, we only need typescript, we are going to get warnings in our install logs (which are noisy anyhow) and figuring out "Oh, this is OK, it is vite-plugin-checker but we can ignore this" makes an exception you need to make time and again.

ESLint

I'm sure there is a good reason for it, but seems a bit odd that in order to do type checking one needs ESLint. Many of us arriving to Vite from Webpack frameworks (RCA, NextJS) are familiar with fork-ts-checker-webpack-plugin.

Is this Approach Scalable?

What if there are (and over the years there will be some) other checks that are needed? Would having a monolith supporting 20 different technologies be a sustainable approach?

What will happen if Typescript introduce breaking changes and so is ESlint, and so will Stylelint? This library will have to decide when to bump a major version, or it'll have to support all permutations (8 in this case). What about testing? Also support in this library all permutations?

Final Thoughts

Anyhow, this issue is a bit more on the conceptual/architectural side, and being a big and breaking change, happy for it to be closed.

[wassim-ben-amor]

Hello, do you agree that when using a bundler such as tsup to generate a common config, then the build will fail because of missing dependencies ? I guess the bundler will try to resolve all the imports, so when vls for example is not installed it will surely fail. I'm not sure what is the workaround for this.