eslint / generator-eslint

A Yeoman generator to help with ESLint development

ESLint

Website | Configure ESLint | Rules | Contribute to ESLint | Report Bugs | Code of Conduct | Twitter | Discord | Mastodon

ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code. In many ways, it is similar to JSLint and JSHint with a few exceptions:

• ESLint uses Espree for JavaScript parsing.
• ESLint uses an AST to evaluate patterns in code.
• ESLint is completely pluggable, every single rule is a plugin and you can add more at runtime.

Table of Contents

1. Installation and Usage
2. Configuration
3. Code of Conduct
4. Filing Issues
5. Frequently Asked Questions
6. Releases
7. Security Policy
8. Semantic Versioning Policy
9. Stylistic Rule Updates
10. License
11. Team
12. Sponsors
13. Technology Sponsors

Installation and Usage

Prerequisites: Node.js (^18.18.0, ^20.9.0, or >=21.1.0) built with SSL support. (If you are using an official Node.js distribution, SSL is always built in.)

You can install and configure ESLint using this command:

npm init @eslint/config@latest

After that, you can run ESLint on any file or directory like this:

./node_modules/.bin/eslint yourfile.js

Configuration

After running npm init @eslint/config, you'll have an eslint.config.js (or eslint.config.mjs) file in your directory. In it, you'll see some rules configured like this:

import pluginJs from "@eslint/js";
export default [ pluginJs.configs.recommended, ];

The names "semi" and "quotes" are the names of rules in ESLint. The first value is the error level of the rule and can be one of these values:

• "off" or 0 - turn the rule off
• "warn" or 1 - turn the rule on as a warning (doesn't affect exit code)
• "error" or 2 - turn the rule on as an error (exit code will be 1)

The three error levels allow you fine-grained control over how ESLint applies rules (for more configuration options and details, see the configuration docs).

Code of Conduct

ESLint adheres to the JS Foundation Code of Conduct.

Filing Issues

Before filing an issue, please be sure to read the guidelines for what you're reporting:

• Bug Report
• Propose a New Rule
• Proposing a Rule Change
• Request a Change

Frequently Asked Questions

I'm using JSCS, should I migrate to ESLint?

Yes. JSCS has reached end of life and is no longer supported.

We have prepared a migration guide to help you convert your JSCS settings to an ESLint configuration.

We are now at or near 100% compatibility with JSCS. If you try ESLint and believe we are not yet compatible with a JSCS rule/configuration, please create an issue (mentioning that it is a JSCS compatibility issue) and we will evaluate it as per our normal process.

Does Prettier replace ESLint?

No, ESLint and Prettier have different jobs: ESLint is a linter (looking for problematic patterns) and Prettier is a code formatter. Using both tools is common, refer to Prettier's documentation to learn how to configure them to work well with each other.

Why can't ESLint find my plugins?

• Make sure your plugins (and ESLint) are both in your project's package.json as devDependencies (or dependencies, if your project uses ESLint at runtime).
• Make sure you have run npm install and all your dependencies are installed.
• Make sure your plugins' peerDependencies have been installed as well. You can use npm view eslint-plugin-myplugin peerDependencies to see what peer dependencies eslint-plugin-myplugin has.

Does ESLint support JSX?

Yes, ESLint natively supports parsing JSX syntax (this must be enabled in configuration). Please note that supporting JSX syntax is not the same as supporting React. React applies specific semantics to JSX syntax that ESLint doesn't recognize. We recommend using eslint-plugin-react if you are using React and want React semantics.

What ECMAScript versions does ESLint support?

ESLint has full support for ECMAScript 3, 5, and every year from 2015 up until the most recent stage 4 specification (the default). You can set your desired ECMAScript syntax and other settings (like global variables) through configuration.

What about experimental features?

ESLint's parser only officially supports the latest final ECMAScript standard. We will make changes to core rules in order to avoid crashes on stage 3 ECMAScript syntax proposals (as long as they are implemented using the correct experimental ESTree syntax). We may make changes to core rules to better work with language extensions (such as JSX, Flow, and TypeScript) on a case-by-case basis.

In other cases (including if rules need to warn on more or fewer cases due to new syntax, rather than just not crashing), we recommend you use other parsers and/or rule plugins. If you are using Babel, you can use @babel/eslint-parser and @babel/eslint-plugin to use any option available in Babel.

Once a language feature has been adopted into the ECMAScript standard (stage 4 according to the TC39 process), we will accept issues and pull requests related to the new feature, subject to our contributing guidelines. Until then, please use the appropriate parser and plugin(s) for your experimental feature.

Which Node.js versions does ESLint support?

ESLint updates the supported Node.js versions with each major release of ESLint. At that time, ESLint's supported Node.js versions are updated to be:

1. The most recent maintenance release of Node.js
2. The lowest minor version of the Node.js LTS release that includes the features the ESLint team wants to use.
3. The Node.js Current release

ESLint is also expected to work with Node.js versions released after the Node.js Current release.

Refer to the Quick Start Guide for the officially supported Node.js versions for a given ESLint release.

Where to ask for help?

Open a discussion or stop by our Discord server.

Why doesn't ESLint lock dependency versions?

Lock files like package-lock.json are helpful for deployed applications. They ensure that dependencies are consistent between environments and across deployments.

Packages like eslint that get published to the npm registry do not include lock files. npm install eslint as a user will respect version constraints in ESLint's package.json. ESLint and its dependencies will be included in the user's lock file if one exists, but ESLint's own lock file would not be used.

We intentionally don't lock dependency versions so that we have the latest compatible dependency versions in development and CI that our users get when installing ESLint in a project.

The Twilio blog has a deeper dive to learn more.

Releases

We have scheduled releases every two weeks on Friday or Saturday. You can follow a release issue for updates about the scheduling of any particular release.

Security Policy

ESLint takes security seriously. We work hard to ensure that ESLint is safe for everyone and that security issues are addressed quickly and responsibly. Read the full security policy.

Semantic Versioning Policy

ESLint follows semantic versioning. However, due to the nature of ESLint as a code quality tool, it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, we've defined the following semantic versioning policy for ESLint:

• Patch release (intended to not break your lint build)
  • A bug fix in a rule that results in ESLint reporting fewer linting errors.
  • A bug fix to the CLI or core (including formatters).
  • Improvements to documentation.
  • Non-user-facing changes such as refactoring code, adding, deleting, or modifying tests, and increasing test coverage.
  • Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
• Minor release (might break your lint build)
  • A bug fix in a rule that results in ESLint reporting more linting errors.
  • A new rule is created.
  • A new option to an existing rule that does not result in ESLint reporting more linting errors by default.
  • A new addition to an existing rule to support a newly-added language feature (within the last 12 months) that will result in ESLint reporting more linting errors by default.
  • An existing rule is deprecated.
  • A new CLI capability is created.
  • New capabilities to the public API are added (new classes, new methods, new arguments to existing methods, etc.).
  • A new formatter is created.
  • eslint:recommended is updated and will result in strictly fewer linting errors (e.g., rule removals).
• Major release (likely to break your lint build)
  • eslint:recommended is updated and may result in new linting errors (e.g., rule additions, most rule option updates).
  • A new option to an existing rule that results in ESLint reporting more linting errors by default.
  • An existing formatter is removed.
  • Part of the public API is removed or changed in an incompatible way. The public API includes:
    • Rule schemas
    • Configuration schema
    • Command-line options
    • Node.js API
    • Rule, formatter, parser, plugin APIs

According to our policy, any minor update may report more linting errors than the previous release (ex: from a bug fix). As such, we recommend using the tilde (~) in package.json e.g. "eslint": "~3.1.0" to guarantee the results of your builds.

Stylistic Rule Updates

Stylistic rules are frozen according to our policy on how we evaluate new rules and rule changes. This means:

• Bug fixes: We will still fix bugs in stylistic rules.
• New ECMAScript features: We will also make sure stylistic rules are compatible with new ECMAScript features.
• New options: We will not add any new options to stylistic rules unless an option is the only way to fix a bug or support a newly-added ECMAScript feature.

License

Team

These folks keep the project moving and are resources for help.

Technical Steering Committee (TSC)

The people who manage releases, review feature requests, and meet regularly to ensure ESLint is properly maintained.

Nicholas C. Zakas

Francesco Trotta

Milos Djermanovic

Reviewers

The people who review and implement new features.

唯然	Nitin Kumar

Committers

The people who review and fix bugs and help triage issues.

Josh Goldberg ✨

Tanuj Kanti

Website Team

Team members who focus specifically on eslint.org

Amaresh S M

Strek

Percy Ma

Sponsors

The following companies, organizations, and individuals support ESLint's ongoing maintenance and development. Become a Sponsor to get your logo on our README and website.

Platinum Sponsors

Gold Sponsors

Silver Sponsors

Bronze Sponsors

Technology Sponsors

• Site search (eslint.org) is sponsored by Algolia
• Hosting for (eslint.org) is sponsored by Netlify
• Password management is sponsored by 1Password

generator-eslint's Issues

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.

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.

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)

[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.

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.

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.

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

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?

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.

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.

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?

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.

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?

What version of eslint does this support?

Ready for release

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

Originally posted by @bmish in #117 (comment)

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

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).

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.

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))

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

adding .eslintrc

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

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.

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.

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

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?

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 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.

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.

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.

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?

Update rule generator for 1.0.0

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

Working on this.

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)

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.

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.

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.

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.

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.

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.

$hbp

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.

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 id regex does not accept numbers

this intentional? or should I fix?

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).

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

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

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?

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

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.