The problem with import/no-unresolved, which warns against (supposedly) invalid imports, is that it often runs into false positives, because it essentially needs to mimic in its own little world what the import actually does. To do this reliably, it needs special resolvers (e.g. TypeScript aliases, Webpack and Vite asset imports). This is a fractured ecosystem and has even lead to a fork of the plugin itself (eslint-plugin-i). And when it doesn't work, it is very annoying and confusing when ESLint is not in agreement with what the editor/IDE shows.

I think the cost of keeping eslint-plugin-import in sync with whatever the bundler is doing under the hood isn't worth the benefit. In fact, this might not be something that should be part of the linter config at all (kind of like how ESLint doesn't do formatting for us because we have Prettier, imports should be a concern of TypeScript or the bundler). To take the point further, a passed ESLint check does not guarantee that tsc will succeed, so there will always be a need for both.

For this reason I am suggesting that we disable the no-unresolved rule. The other rules which we use as part of the recommended preset should still work as long as the plugin can resolve the import, but it should shut up if it can't and let the big boys do the talking. For reference, these rules are:

import/default: Ensure a default export is present, given a default import.

import/named: Ensure named imports correspond to a named export in the remote file.

import/namespace: Ensure imported namespaces contain dereferenced properties as they are dereferenced.

Regarding the idea of outright removing this plugin: unfortunately we lose import/order with it and to be honest I am pretty fond of that one because it is nice not having to think about import order at all while still having some kind of structure that isn't just "first come first served" (I might get contested on this :) )

Unfortunately the built-in sort-imports auto-fix does not do line reordering (https://eslint.org/docs/latest/rules/sort-imports).

There is an alternative which looks to be more powerful (and opinionated): https://github.com/lydell/eslint-plugin-simple-import-sort but switching to it will most likely be a breaking change.

This issue was prompted by the release of ESLint v9

Since there are a lot of packages at play here, that are all updated individually, it's easy to reach a configuration that does not play nicely together (e.g. typescript-eslint v7 with @next/eslint-plugin-next which is simply just incompatible since the next plugin requires typescript-eslint v6).

By setting up a small project that uses @atmina/linting as dependency and a little GitHub Action to try and lint that project using this package, we can easily spot which upgrades contain breaking changes and which are incompatible with each other. That way, we can prevent renovate from upgrading dependencies that would break the plugin if released.

This file is always generated and therefore should not be formatted.

If it is formatted, we would also be forced to format it in the CI when doing staleness checks.

It is currently not covered by the .prettierignore

Prettier themselves mention using eslint-plugin-prettier as not recommended here: https://prettier.io/docs/en/integrating-with-linters.html#notes

Generally we should reserve prettier for formatting and ESLint for everything else. With the Prettier plugin, ESLint is also run as formatter which is rather slow. This is especially annoying when having eslint --fix run on save which then very slowly starts to format things. Then seeing the quick flash of prettier afterwards, reminding you at this could all have been done a lot quicker.

It also isolates issues in the CI more clearly (so a formatting issue doesn't automatically fail two jobs instead of one).

Here is a list of small improvements that could be made to our current linting setup to improve cleaning up code in the frontend (and TypeScript in general):

• Prohibit foo={true} on JSX tags, foo is enough as attribute
• Enforce self-closing tags instead of having expanded empty tags <div></div> should be <div />
• Enforce expression bodies of arrow function () => { return "foo"; } should become () => "foo"
• Remove unnecessary fragments: <><div /></> becomes <div />
• Trim classNames (if possible) w-full h-12 (trailing space) becomes w-full h-12

This should be released at least as a new minor version.

Allow importing things like the Prettier config from TypeScript code with the expected type.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Currently the package pulls in dependencies which might not always be required (e.g. React). This makes the setup very easy right now but could bloat in the future.

Approach 1:

• Mark dependencies like eslint-plugin-react as peer dependencies
• Mark peer dependencies as optional if they aren't strictly required in all cases
• Install peer dependencies as part of the setup script (depending on the presets used)
• No monorepo required
• Plugins leak into the project's package.json (like in the old days)

Approach 2:

• Split up into separate packages with (non-peer) dependencies (e.g. linting-preset-react)
• Setup script assembles these packages
• Monorepo
• Plugins remain encapsulated

I think the second approach would also benefit projects which are themselves monorepos (microfrontends anyone?). But versioning everything might become a bit of a pain point.

console.log is commonly used in our code to throw in quick and dirty debugging. However it is sometimes forgotten to be removed.

We make frequent use of console.warn, console.error in different places in our web applications for development messages. We also use console.info in CLI scripts to print progress output.

I thus propose adding no-console: ["error", { allow: ["info", "warn", "error"] }] to our base configuration in order to reduce the chances of debugging console statements making it to production.

This does not yet include eslint-plugin-react-hooks, which would be a nice inclusion :)

Not sure why, but Prettier seems to be going through image files. That doesn't make a lot of sense; maybe it's trying to find code embedded in other file formats, so it defaults to looking everywhere?

GraphQL files should be indented with 2 spaces