Open rosshadden opened 4 years ago
Seems like a good plan @rosshadden. Some additional thoughts:
.eslintrc.js
file (https://eslint.org/docs/user-guide/configuring#configuration-file-formats) might be helpful in that it supports dynamic config (for example check whether NODE_ENV
is "test" to turn on test globals). I assume there is an equivalent for dynamic config in a plugin package.I went to open this ticket but it was already here. This change would be really helpful and for pure node linting the current code has a lot of bloat.
Problem
Right now our main and only config in this project is both react-specific and test-specific. It uses the plugins
jest
,jsx-ally
,react
, andreact-hooks
. It also sets thejest
,mocha
,browser
, andnode
environments to true.The above has the following implications:
describe
andtest
, are allowed in all code, testing or otherwisewindow
anddocument
, are allowed in all code, browser or otherwiserequire
andprocess
, are allowed in all code, node or otherwiseSolution
We can make our config modular. We will have a base config file that is universally applicable and env-agnostic. No node config, no browser config, no tests config. We can then have specific environment files that extend these. One for browser, one for specifically react which would extend browser, one for node, one for tests.
The official eslint docs for doing so can be found here.
An example node environment config:
Using this same pattern we could also make different "modules" which would have config for certain agnostic libraries or scenarios. Things like MongoDB, jsdoc, jest, react, or lodash. For example, consider the popular library lodash. A lodash module would specify the
lodash
plugin, extend the recommended config, and then override any rules we may desire. This example would look something like this:Projects (including this project which can eat its own dogfood) could then cherry-pick the modules they want, or use our pre-configured environments which should be good for most of our uses.
Breaking changes
This will have ramifications. My desired plan is to rely on semver, where people should not blindly update over a major version without doing their research first.
eslint-plugin-react-hooks
will be changed todependencies
in this project and they will never need to manually be installed in other projects. Eslint recommends that plugins be peer dependencies, however when modularizing eslint configs it is more common to make plugins dependencies of the lint config, not peer dependencies. For some examples see Shopify, Facebook, React App, Canonical, Alloy, Supermind, and ES.