eslint / generator-eslint

A Yeoman generator to help with ESLint development

generator-eslint

The ESLint generator for Yeoman. This generator is intended to aid development within the ESLint project. It is designed to work within the top-level eslint directory.

Installation

First and foremost, you must have Node.js and npm installed. If you don't have Node.js installed, please download and install the latest version.

Requirements

• Node.js ^18.18.0 || ^20.9.0 || >=21.1.0

You must also install Yeoman, if you don't have it installed already. To install Yeoman, you can run this command:

npm i -g yo

With Node.js and Yeoman installed, you can run this command:

npm i -g generator-eslint

Usage

The Yeoman generator currently supports the following commands:

eslint:plugin

If you want to create a new ESLint plugin, make sure you're in the top-level directory where you want the plugin to be created and type:

yo eslint:plugin

You'll be prompted for information about your plugin and it will generate a package.json file, README, and source code for a stub plugin.

eslint:rule

If you want to create a new ESLint rule, make sure you're in the top-level directory of an ESLint repo clone or an ESLint plugin and type:

yo eslint:rule

You'll be prompted for some information and then it will generate the files necessary for a new rule, including the source file, a test file, and a documentation file.

License and Copyright

Copyright OpenJS Foundation and other contributors, <www.openjsf.org>

MIT License

generator-eslint's Issues

Error when running generator

Running yo eslint:plugin produces the following error:

node/6.3.0

module.js:442
    throw err;
    ^

Error: Cannot find module './src/init'
    at Function.Module._resolveFilename (module.js:440:15)
    at Function.Module._load (module.js:388:25)
    at Module.require (module.js:468:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/usr/local/lib/node_modules/generator-eslint/node_modules/gulp-sourcemaps/index.js:4:9)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:458:32)
    at tryModuleLoad (module.js:417:12)
    at Function.Module._load (module.js:409:3)

npm test script in generated package.json does not work

Running yo eslint:plugin and then yo eslint:rule will produce a plugin project with a test script that does not work. npm test will not run any tests and report as passing.

Upgrade yeoman-generator to latest

I'd like to upgrade yeoman-generator to latest. We're depending on yeoman-generator ^0.22.5, but the latest is 0.24.1. Due to how semver ranges work, ^0.22.5 only picks up later patch releases, not later minor releases (due to major version being 0).

Reasons I want to do this:

1. It's always great to use latest software
2. Opportunity to rewrite prompt hooks to use promises instead of async callbacks (though I'll check node.green first)
3. Inquirer (dependency of yeoman-generator) is also updated to use 1.x (instead of 0.11), so should be a much improved experience.

The last point is potentially important for #42. We have an issue where single quotes in user input are being transformed into double quotes. I have no solid lead on why this is, but one possibility comes from Inquirer changing its dependencies between 0.11 and 1.x. They removed "readline2" in favor of Node's core readline. So I'd like to upgrade to see if the quote transform issue goes away as a result.

Update files' copyright and licensing to match jQuery foundation standards

(Description forthcoming.)

Edit: Aw, hell, I was too slow and @nzakas already beat me to it. Sorry about that.

404 on install

> npm i -g generator-eslint

npm http 404 https://registry.npmjs.org/generator-eslint/-/generator-eslint-0.0.3.tgz
npm ERR! fetch failed https://registry.npmjs.org/generator-eslint/-/generator-eslint-0.0.3.tgz

Add support for ESLint configs

lemonmade/generator-eslint-config is a Yeoman generator for ESLint configs. I opened lemonmade/generator-eslint-config#1 to discuss merging the two projects together, but I haven't gotten a response. What do you think about including @lemonmade’s code in this project?

Fix linting inconsistencies in templates

I'm planning to apply the default prettier formatting to all the template files. The goal is that a generated plugin/rule will be fully-ready (no violations) for anyone who wants to use prettier to lint their ESLint plugin.

Update rule generator for 1.0.0

Since we changed from ESLintTester to RuleTester, we need to update the generator.

Working on this.

Missing meta.messages property

Suggestion

Support the recommended rule eslint-plugin/prefer-message-ids by providing a meta.messages property using a MessageId. Currently, running yo eslint:rule does not add this property to the generated lib/rules/<rule-id>.js rule.

Background

• The rule eslint-plugin/prefer-message-ids from eslint-plugin-eslint-plugin is part of the recommended config for this plugin where it says:

When reporting a rule violation, it's preferred to provide the violation message with the messageId property instead of the message property.

Documentation

• MessageIds

Unnecessary `category` field in template for plugin-based rules

Hi there! I'm working on writing up a blog post on how to get started writing an ESLint plugin and I wanted to showcase this tool as a quick getting-started point for new users since I found it super helpful to spin up a project and familiarize myself with the structure.

One thing that I noticed in the rule template is the category field:

generator-eslint/rule/templates/_rule.js

Line 17 in dff57cc

category: "Fill me in",

Based on the information I could find about it (via the JSDoc comment in the TypeScript definitions and the note on the Developer Guide > Working with Rules page), this sounds like a field that is optional and only used for core rules, not plugin-based rules.

Can we update the template to conditionally add that section for core-rules only?

Additionally, I did some digging in the ESLint repo and I couldn't find any rules with category filled in - that field seems to only be referenced in some test code (tests/lib/cli-engine/formatters/html.js and tests/lib/cli-engine/formatters/json-with-metadata.js).

Is this a field that's still used at all? If not, let's remove it from the template (and the documentation site).

Remove JSDoc file comments from generated files

I'm not a fan of the JSDoc comments that we add to the top of all the generated JavaScript files (rule implementation file, test file, etc):

/**
 * @fileoverview <%= desc %>
 * @author <%= userName %>
 */

Why not?

• The rule description gets repeated in too many places (not DRY), including these comments and in meta.docs.description. As a result, the description in the comments is usually out-of-sync with the property. And having to update multiple places makes it more of a hassle to update rule descriptions.
• Over-time, there are often many authors that contributed to a rule, not just the original creator.
• Having a prompt to ask for author name also makes it more tedious to use the rule generator (this is one of many prompts that gets asked).

What do you think? Let me know if anyone actually finds these comments valuable.

Shouldn't mocha be listed as a devDependency?

I wasn't able to get the tests to run until I installed mocha-cli globally and mocha locally.

npm install -g mocha-cli
npm install --save-dev mocha

Maybe I'm missing something, but shouldn't mocha be included as a dev dependency? And can we avoid depending on the presence of the mocha command by referencing ./node_modules/mocha/bin/mocha directly?

Should generator-eslint have a main file?

Hi folks, I was looking at the package.json when I noticed that there was a "main" entry pointing to "app/index.js". That file doesn't exist. Furthermore it seems Yeoman uses some magic to read the filesystem and gather what it needs to know.

Since neither the user nor Yeoman needs to read a main file, should it be removed?

adding .eslintrc

• it can be useful.
• the default settings of ESLint disallow global-strict, so it can useful

Plugin generator seems to depend on old ESLint

Probably the cause is https://github.com/eslint/generator-eslint/blob/master/plugin/templates/_package.json#L19

Upgrade dependencies

This package is quite old and it’s been a while since it’s been updated. We should go through and upgrade all dependencies to their most recent versions.

eslint-release and yo in particular must be upgraded.

rule id regex does not accept numbers

this intentional? or should I fix?

What version of eslint does this support?

[docs] let's explain in readme the questions that this CLI will ask

This CLI will ask the following questions:

Does this plugin contain custom ESLint rules?

Let's explain in the readme, what is not a custom ESLint rule and how it differs from a custom-one.

Does this plugin contain one or more processors?

Let's explain in the readme, what are the processors, what they do? Which ones are available? Mind you, the ESLint documentation mentions only custom formatters and custom parsers, there is no mention of processors. Let's explain what those are.

consider add eslint-plugin-eslint-plugin and eslint-plugin-node

ESLintTester uses eslint instead of eslint.linter

the default is

"use strict";

//------------------------------------------------------------------------------
// Requirements
//------------------------------------------------------------------------------

var eslint = require("../../../lib/eslint"),
    ESLintTester = require("eslint-tester");

//------------------------------------------------------------------------------
// Tests
//------------------------------------------------------------------------------

var eslintTester = new ESLintTester(eslint);
eslintTester.addRuleTest("lib/rules/not-exist", {

which than, no test is pass, but if i replace to:

var eslintTester = new ESLintTester(eslint.linter);

it works.

Error: You must provide a `choices` parameter

I've tried to get the generator working both on Unix and Mac, but keep running into this error when running yo eslint:plugin.

mac main: yo --version
1.4.7
mac main: yo --generators
eslint
mac main: yo eslint:plugin
? What is your name? Alex
? What is the plugin ID? test
? Type a short description of this plugin: Test


/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:579
    throw e;
          ^
Error: You must provide a `choices` parameter
    at Prompt.throwParamError (/usr/local/lib/node_modules/yo/node_modules/inquirer/lib/prompts/base.js:88:9)
    at new Prompt (/usr/local/lib/node_modules/yo/node_modules/inquirer/lib/prompts/checkbox.js:28:10)
    at PromptUI.fetchAnswer (/usr/local/lib/node_modules/yo/node_modules/inquirer/lib/ui/prompt.js:92:16)
    at /usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:4599:20
    at tryCatcher (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:567:29)
    at InnerObserver.onNext (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:4806:43)
    at InnerObserver.tryCatcher (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:567:29)
    at AutoDetachObserverPrototype.next (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:5274:51)
    at AutoDetachObserver.Rx.internals.AbstractObserver.AbstractObserver.onNext (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1710:35)
    at InnerObserver.onNext (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:3409:91)

Looks like inquirer is throwing an error, but not sure if it seems to work for others? I've tried older verison of yo, generator, and inquirer, and could not find a working combination.

Issues around quotes in generated files

I remember seeing oddities with regard to single and double quotes used in input values, and how they get transformed into output files.

Issues found/confirmed:

• Description in rule generator's rule file is HTML-escaped and shouldn't be (but double quotes should be backslash-escaped).
  • Confirmed here and here.
• Invalid code snippet in rule generator's test file is HTML-escaped and shouldn't be (but double quotes should be backslash-escaped).
  • Confirmed here.
• Description and username in plugin generator's package.json file are HTML-escaped
  • Confirmed here and here.
• Single quotes in input are replaced with double quotes throughout. Need to determine if yeoman, our generator code, or something else causes this. Extracted to #44.

Not an issue:

• HTML-escaping of quotes in Markdown files: This is not a problem, see here and here.
  • Only issue is why single-quotes turn into double-quotes. See #44.

When I use `yo eslint:plugin` , I get the following error:

When I use yo eslint:plugin , I get the following error:
TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))

Convert to ESM

I'd like to see if we can convert this package to ESM.

https://blog.sindresorhus.com/hello-modules-d1010b4e777b

That would likely be the final change before the next major release.

the default config does not use .eslintrc.js

this makes me somewhat confused. Should it be appropriate to add “RuleTester.setDefaultConfig” to the initial code?

Update to modern eslint

Current listing in the generated plugin package.json is ~1.2.0 which is a couple major revisions behind where eslint is today.

should `eslint` be a devDependency or peerDependency?

Hi.

http://eslint.org/docs/developer-guide/working-with-plugins
mentions that eslint should be defined in the peerDependencies section of your plugin's package.json.

However the yeoman generator adds eslint to the devDependencies section.

generator-eslint/plugin/templates/_package.json

Line 19 in 67ccdc5

"eslint": "~1.2.0"

Which is correct?

Thanks.

Update to generate eslint 9.0 plugins

I'm just getting started with eslint plugins, so I'm not sure how big of a deal or necessary this is, but the generator currently generates a project that uses eslint 8.19.

Rule/Plugin generator

Now that ESLint supports plugins, it would be nice to either modify generator or create a new one to support generating plugins and adding rules inside plugins. Rules for plugins probably don't need to be nested quite as deeply as in ESLint itself. Also tests should require ESLint as external package.

$hbp

Chore: Use .yml extension for ESLint config and use mocha env

Two simple changes:

• Rename .eslintrc --> .eslintrc.yml
• Add tests/.eslintrc.yml with mocha environment and remove /* global */ blocks

PR forthcoming.

Should we remove node 0.10, 0.12 from TravisCI config?

ESLint no longer supports Node versions less than 4.x and has removed 0.10 and 0.12 from its Travis config. Should we do the same?

Note that this issue will block any transition to ES6 in this repo (without using a transpiler).

Docs language change once the core rules are updated?

@pedrottimark has been going through our rule documentation to try to standardize some of the language and structure. I assume that the eslint:rule generator should also be similarly updated, once some of the new standards have been fully established.

EDIT: Proposal for this issue is as follows:

• We should fix the generated .md files to use the preferred rule docs example callouts:
  • Examples of **incorrect** code
  • Examples of **correct** code

This allows for easier integration with core ESLint guidelines, and plugin authors can choose to use alternative language if they prefer.

Caching problem in tests (same generator and/or same prompts are used in different tests)

Extracted from #42. That issue talks about us not escaping double quotes correctly when putting user input in JS code; this one talks about single quotes being replaced by double quotes somewhere in the generator internals.

Of course it's a caching problem.

Ready for release

Let's do a 3.1.0 release in the near future.

Originally posted by @bmish in #117 (comment)

lookups.flatMap is not a function

yo eslint:plugin /Users/nuanfeng/.nvm/versions/node/v10.15.3/lib/node_modules/yo/node_modules/yeoman-environment/lib/resolver.js:70 filePatterns: lookups.flatMap(prefix => [${prefix}//index.ts, ${prefix}//index.js, ${prefix}//index.cjs, ${prefix}//index.mjs]), TypeError: lookups.flatMap is not a function

Release v4

I think we are ready to release a patch version of generator-eslint with the current changes that have been merged already.

In addition, starting to prepare for a major version release (generator-eslint v4):

• #133
• #134
• #135
• #136

Regarding major version release timing:

• We could do a major release now/soon and then perform a minor release to upgrade the plugin template to ESLint v9 when that gets released in the coming months (get changes out sooner)
• Or we could wait until ESLint v9 is released (not strictly necessary but could do this to align the release schedule or ensure full preparedness for ESLint v9)

Feature Request: Have generator adhere to .editorconfig

I know that the ESLint core project uses an indentation size of 4, however the world is a magically diverse place with many different indentation preferences.

Would you accept a PR that would have yo eslint:rule adhere to the .editorconfig, if present?

Lint generator-eslint with eslint

Seems like this project should be linted with eslint and that jshint can be removed once eslint linting is in place.

Not compatible with recent Node versions (not compatible with [email protected])

Here is the output after trying to install with Node 8.11.1. If I understand correctly, it is because this is using a fairly outdated version of got).

❯ npm i -g generator-eslint

npm ERR! code ENOTSUP
npm ERR! notsup Unsupported engine for [email protected]: wanted: {"node":">=0.10.0 <7"} (current: {"node":"8.11.1","npm":"5.6.0"})
npm ERR! notsup Not compatible with your version of node/npm: [email protected]
npm ERR! notsup Not compatible with your version of node/npm: [email protected]
npm ERR! notsup Required: {"node":">=0.10.0 <7"}
npm ERR! notsup Actual:   {"npm":"5.6.0","node":"8.11.1"}

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/othon/.npm/_logs/2018-04-01T18_42_39_617Z-debug.log

Mocha as generated dev dependency

Running through a fresh install, the generated files don't have mocha as a dev dependency, but the supplied test command relies on it.

Repro steps:

• Set up a new plugin: yo eslint:plugin
• Set up a new rule: yo eslint:rule
• Install dependencies: npm install
• Try to run test npm test
• Test run fails with following message:

> mocha
sh: mocha: command not found
npm ERR! Test failed.  See above for more details.

Proposed Resolution:
Add mocha as a dev dependency for the generated project.

Generator hangs after generating files

I'm on Windows running a bash-like shell, so it's probably a weird setup. But I wanted to open this in case there was something we could do in code to mitigate this. For example, if we aren't calling inquirer's callback, that can appear to hang on some platforms.

In terms of functional impact, there is none-- files are generated and I just have to sigint the process. But if that's preventable, all the better, right?

I'll investigate this-- just wanted to put this out here in case anyone had any insights.

Update rule generator to use new format

In changing the rule format for ESLint, we forgot to update the format for the rule generator here to use the new format.

It would be good to get this package updated to use the new rule format so we can continue pointing people to this package as the best way to get started with new rules.

Generated plugin crashes when installed due to incorrect export

What version of generator-eslint?

1.0.2

What did you do?

• Installed and ran yo eslint:plugin.
• Didn't modify any project setup, just added a rule and tests (which passed).
• Added plugin to a project using eslint.
• Ran eslint on said project.

What went wrong?

ESlint resulted in this error

fs.js:813
  return binding.readdir(pathModule._makeLong(path));
                                    ^

Error: ENOENT: no such file or directory, scandir './rules'

I suspect its because requireIndex expects a __dirname to be passed in as well, which isn't being passed inside index.js.

Where do I find information on a plugin id?

yo eslint:plugin
...
What is the plugin ID?

Good question right? The eslint plugin documentation here doesn't explain it nor does the generator documentation here

I will keep googling and answer this when I've figured it out.

Switch from master to main as primary branch

• GitHub: Merge any outstanding pull requests
• Local: Ensure you're up-to-date locally git fetch && git reset --hard origin/master
• Local: Push a main branch: git checkout -b main && git push origin main
• GitHub: Under Settings -> Branches: Set the default branch to main
• GitHub: Under Settings -> Branches: Set up branch protection for the main branch
• GitHub: Under Settings -> Branches: Remove branch protection for master
• Local: Delete remote master branch git push origin :master
• Local: Delete master branch git branch -d master

Add a Typescript variant

Some community ESLint plugins (e.g. https://github.com/testing-library/eslint-plugin-testing-library) use typescript. I think it'd be a great idea to have a typescript variant of the generated boilerplate. It'd be something similar to CRA: npx create-react-app my-app --template typescript.

I am not too familiar with yeoman, so I am not sure if it ought to be a different generator or some kind of a parameter could be passed. In any case, is that something that is of interest to others?