Getting Started guide causes ESLint complaints in .eslintrc.(c)js

[JoshuaKGoldberg]

Before You File a Documentation Request Please Confirm You Have Done The Following...

• I have looked for existing open or closed documentation requests that match my proposal.
• I have read the FAQ and my problem is not listed.

Suggested Changes

When starting a TypeScript repository from scratch using our docs, we tell folks to use this as their .eslintrc.cjs config:

module.exports = {
  extends: ['eslint:recommended', 'plugin:@typescript-eslint/recommended'],
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  root: true,
};

However, that results in an ESLint error on the .eslintrc.cjs file when viewed in VS Code!

'module' is not defined. eslint [no-undef](https://eslint.org/docs/rules/no-undef)

This is confusing. We should fix the code and/or docs so that our first run experience doesn't include ESLint errors for problems that don't exist. I'm not sure what the correct solution is, though. A few options:

• Use env: { node: true } for specifically this file or files like it?
• Explicitly disable the rule
• Don't change the config, and add a warning to the docs

...I don't love any of those 🤔. How are users "supposed" to fix this?

(using the flat config system is not a viable solution yet, as flat configs are still considered experimental)

This issue came out of a Twitch stream with @Jutanium. 👋

Affected URL(s)

https://typescript-eslint.io/getting-started

[armano2]

to be precise you actually want to enable eaither /* eslint-env commonjs */ or /* eslint-env node */

this is described in https://eslint.org/docs/latest/use/configure/language-options

---

in teory we could add override to config that enables it for cjs and cts, but i don't think this is a good idea

---

node - Node.js global variables and Node.js scoping.
commonjs - CommonJS global variables and CommonJS scoping (use this for browser-only code that uses Browserify/WebPack).

[JoshuaKGoldberg]

Related: eslint/create-config#59