Thanks for attempting this. I’m not comfortable with reading an environment variable for this purpose — that’s just one assumption too many when determining how ESLint should behave.

We did recently merge this RFC that covers this use case: https://github.com/eslint/rfcs/pull/63

(This is not an RFC.)

In a few RFCs so far, it seems like the "Documentation" section has boiled down to "We will describe how this feature works in the documentation." This commit updates the template to ask some broader questions about how the feature will be communicated to users.

We decided not to move forward this change, so closing.

Gotcha, thanks.

Status update: we still need to leave this PR open for public comment for another nine days per our RFC process. Then we go into final commenting for seven days. It looks like there’s good alignment on the team, though, so I don’t expect any hiccups along the way.

Thanks for catching and fixing this!

<!-- Thank you for contributing!

ESLint adheres to the [JS Foundation Code of Conduct](https://js.foundation/community/code-of-conduct).

-->

Prerequisites checklist

• [X] I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update [ ] Bug fix (template) [ ] New rule (template) [ ] Changes an existing rule (template) [ ] Add autofixing to a rule [ ] Add a CLI option [ ] Add something to the core [X] Other, please explain:

Removes mistakenly added eslint-7.8.0.tgz from the root dir.

<!-- If the item you've checked above has a template, please paste the template questions below and answer them. (If this pull request is addressing an issue, you can just paste a link to the issue here instead.) -->

<!-- Please ensure your pull request is ready:

- Read the pull request guide (https://eslint.org/docs/developer-guide/contributing/pull-requests)
- Include tests for this change
- Update documentation for this change (if appropriate)

-->

<!-- The following is required for all pull requests: -->

What changes did you make? (Give an overview)

Removed the file.

Is there anything you'd like reviewers to focus on?

Agenda item: It's like to revisit the discussion around a community manager. My thinking has changed a bit (mostly about the title and also about how many people we'd want), and want to run my latest thinking by the team to see if we want to move forward.

See the original comment: https://github.com/eslint/website/pull/783#issuecomment-690144168

You most likely have a commit that was created using a different email address.

Tell us about your environment Environment Info:

Node version: v10.17.0 npm version: v6.11.3 Local ESLint version: v7.9.0 (Currently used) Global ESLint version: Not found

What parser (default, @babel/eslint-parser, @typescript-eslint/parser, etc.) are you using? ecmaVersion: 6 sourceType: "script"

Please show your full configuration:

<details> <summary>Configuration</summary>

module.exports = {
  env: {
    commonjs: true,
    es6: true,
    node: true
  },
  extends: [
    'eslint:recommended'
  ],
  parserOptions: {
    ecmaVersion: 6,
    sourceType: "script",
  },
  rules: {
    'no-console': 'warn',
    'no-debugger': 'warn',
    'block-scoped-var': "warn",
    'no-multi-spaces': "warn",
    'array-bracket-newline': ["warn", "consistent"],
    'block-spacing': "warn",
    'brace-style': ["warn", "1tbs"],
    'comma-dangle': ["warn", "always-multiline"],
    'comma-spacing': ["warn", {before: false, after: true}],
    'comma-style': ["warn", "last"],
    'eol-last': ["warn", "always"],
    'func-call-spacing': ["warn", "never"],
    'indent': ["error", 4],
    'key-spacing': ["warn", {mode: "minimum", afterColon: true}],
    'keyword-spacing': ["warn", {before: true, after: true}],
    'linebreak-style': ["warn", "unix"],
    'new-parens': ["warn", "always"],
    'newline-per-chained-call': ["warn", {ignoreChainWithDepth: 3}],
    'no-lonely-if': "warn",
    'no-trailing-spaces': "warn",
    'no-unneeded-ternary': "warn",
    'no-whitespace-before-property': "warn",
    'semi-spacing': ["warn", {before: false, after: true}],
    'space-before-blocks': "warn",
    'space-before-function-paren': ["warn", {anonymous: "never", named: "never", asyncArrow: "always"}],
    'space-infix-ops': ["warn", {"int32Hint": true}],
    'space-unary-ops': ["warn", {words: true, nonwords: false}],
    'spaced-comment': ["warn", "always"],
  }
}

</details>

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

<!-- Paste the source code below: -->

exports.updateActions = function(req, res) {
    /* Must have only the changed actions in parameters to be performant TODO IN FRONT*/
    const promises = []
    for (const action of req.body) {
        promises.push(
            models.Action.update(action, {
                where: {
                    actionId: action.actionId,
                },
            }), // Problem is here
        )
    }
    Promise.all(promises).then(() => {
        return res.sendStatus(200);
    }, err => {
        logger.error('%o', err);
        res.sendStatus(500);
    })
}

<!-- Paste the command you used to run ESLint: -->

eslint app/ --ext .js

What did you expect to happen? No error found

What actually happened? Please include the actual, raw output from ESLint.

eslint app/ --ext .js

/home/simonc/projects/sx-projects-back/app/controllers/actionController.js 33:9 error Parsing error: Unexpected token )

✖ 1 problem (1 error, 0 warnings)

If I remove the comma (see line "Problem is here") the error disappear but I would like to keep this comma because node understand it correctly and it give better commits (like comma-dangle rule)

Are you willing to submit a pull request to fix this bug? No

some eslint rules are so obnoxious that they deserve to be banned on a kernel level.

Hi team! 👋

I would like to ask if you guys could help us out in getting mysticatea/eslint-utils#7 merged. I already tried contacting @mysticatea in a lot of different ways, but I haven't heard from him since July 16th when he said he would have a look at it the weekend after.

I know OSS relies on the maintainer of the packages and I'm super grateful for all the packages @mysticatea's maintaining, but this PR is blocking (at least) 7 other packages to be able to get ESLint 7 support without any problems. The most important ones are eslint-plugin-testing-library & eslint-config-react-app.

Since @mysticatea seems to be the only person who can publish the package, we're thinking about publishing a fork if this isn't resolved within a week or two. If the @eslint team is willing to take over the package and publish it yourself (since it's a generic enough package) that would be awesome, but we're also willing to take ownership of the package if necessary.

Hopefully we can get this sorted out and we can enjoy all the lovely packages.

Thanks for helping us out! 👊

CC all people involved in the depending PRs: @Belco90 @iansu @ianschmitz @kentcdodds @mrmckeb @nickmccurdy

Just a reminder that this repo is for issues related directly to ESLint. It’s not appropriate to file issues here about a project we don’t maintain just because the maintainer also happens to maintain ESLint.

I guess I’m used to the it.only process of getting that test working and then checking to see if any other tests broke, so that doesn’t bother me too much.

I’m not sold on this proposal as of this moment, but let’s see what others think.

<!-- Thank you for contributing!

ESLint adheres to the [JS Foundation Code of Conduct](https://js.foundation/community/code-of-conduct).

-->

Prerequisites checklist

• [x] I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update [ ] Bug fix (template) [ ] New rule (template) [ ] Changes an existing rule (template) [ ] Add autofixing to a rule [ ] Add a CLI option [ ] Add something to the core [x] Other, please explain:

Refactored a test

<!-- If the item you've checked above has a template, please paste the template questions below and answer them. (If this pull request is addressing an issue, you can just paste a link to the issue here instead.) -->

<!-- Please ensure your pull request is ready:

- Read the pull request guide (https://eslint.org/docs/developer-guide/contributing/pull-requests)
- Include tests for this change
- Update documentation for this change (if appropriate)

-->

<!-- The following is required for all pull requests: -->

What changes did you make? (Give an overview)

I removed the in-memory file system from the CLIEngine tests and replaced it with an actual filesystem. This is important for working on simple config because the in-memory filesystem does all kinds of complicated things to "fake" a filesystem, and it's impossible to reuse that to test that simple config doesn't break anything.

This change keeps all of the tests working the exact same way they did previously, only with an actual filesystem. That will allow me to eventually start using exports from @eslint/eslintrc inside CLIEngine and tell if I broke anything.

I'll need to do the same for the rest of the places in the tests where in-memory filesystems are used, so this is the first of a few such refactors.

Is there anything you'd like reviewers to focus on?

Anything obvious look out of place?

This seems very unexpected. Can you explain why it would be run twice?

I’m a bit worried at how focused this is on the debugger case. Are there any other potential uses?

Can you please describe the purpose of this change?

I think this was included by mistake. Can you delete this file?

<!-- Thank you for contributing!

ESLint adheres to the [JS Foundation Code of Conduct](https://js.foundation/community/code-of-conduct).

-->

Prerequisites checklist

• [x] I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[x] Documentation update [ ] Bug fix (template) [ ] New rule (template) [ ] Changes an existing rule (template) [ ] Add autofixing to a rule [ ] Add a CLI option [ ] Add something to the core [ ] Other, please explain:

<!-- If the item you've checked above has a template, please paste the template questions below and answer them. (If this pull request is addressing an issue, you can just paste a link to the issue here instead.) -->

<!-- Please ensure your pull request is ready:

- Read the pull request guide (https://eslint.org/docs/developer-guide/contributing/pull-requests)
- Include tests for this change
- Update documentation for this change (if appropriate)

-->

<!-- The following is required for all pull requests: -->

What changes did you make? (Give an overview)

Clarifies that a package.json file is necessary to use --init in the Getting Started guide. (it errors currently when there is no package.json file present)

Is there anything you'd like reviewers to focus on?

Is this clear enough?

Agenda item: Let's discuss the changes we'll be making to how we manage Tidelift payments and ensure everyone is signed up.

Yeah, your wording makes sense.

Much better! The only thing we need now is to replace the “OpenJs Foundation” link with the full URL (as we currently have on the site).

And please don’t forget to address the CLA email issue.

Thanks!

I’ll keep an eye out as I go. Node.js ESM support is still considered experimental, so definitely worth following up with them about this issue.

**Note:** `--init` assumes you have a `package.json` file already. If you don't, make sure to run `npm init` or `yarn init` beforehand.

Oops, yes

@molisani the new config system is fairly well defined. You can get more details by visiting the issue I linked to. I really don’t want to add something that will be deprecated once the new config system is complete.

@mdjermanovic we are actually deprecating context.parserPath as part of the config changes. It will be replaced by context.parser.

<!-- ESLint adheres to the Open JS Foundation Code of Conduct: https://eslint.org/conduct

This template is for bug reports. If you are here for another reason, please see below:

1. To propose a new rule: https://eslint.org/docs/developer-guide/contributing/new-rules
2. To request a rule change: https://eslint.org/docs/developer-guide/contributing/rule-changes
3. To request a change that is not a bug fix, rule change, or new rule: https://eslint.org/docs/developer-guide/contributing/changes
4. If you have any questions, please stop by our chatroom: https://eslint.org/chat

Note that leaving sections blank will make it difficult for us to troubleshoot and we may have to close the issue.

-->

Tell us about your environment

eslint : The term 'eslint' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the 
spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ eslint --env-info
+ ~~~~~~
    + CategoryInfo          : ObjectNotFound: (eslint:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

• ESLint Version: ?
• Node Version: v12.18.3
• npm Version: 6.14.6

What parser (default, @babel/eslint-parser, @typescript-eslint/parser, etc.) are you using? default

Please show your full configuration:

<details> <summary>Configuration</summary>

<!-- Paste your configuration below: -->

?

</details>

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

<!-- Paste the source code below: -->

//

<!-- Paste the command you used to run ESLint: -->

eslint --init 

What did you expect to happen? It to do stuff

What actually happened? Please include the actual, raw output from ESLint.

eslint : The term 'eslint' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the 
spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ eslint --init
+ ~~~~~~
    + CategoryInfo          : ObjectNotFound: (eslint:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Are you willing to submit a pull request to fix this bug? No

It's worth noting that this plugin strategy is going to change completely with the new config system in development. As such, we aren't making any further changes to the current config system (it will make achieving backwards compatibility a lot harder). With the new config system, ESLint will no longer be doing any module resolving and you'll be able to slide in any object from anywhere you so choose.

<!-- Thank you for contributing!

ESLint adheres to the [JS Foundation Code of Conduct](https://js.foundation/community/code-of-conduct).

-->

Prerequisites checklist

• [x] I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[x] Documentation update [ ] Bug fix (template) [ ] New rule (template) [ ] Changes an existing rule (template) [ ] Add autofixing to a rule [ ] Add a CLI option [ ] Add something to the core [ ] Other, please explain:

<!-- If the item you've checked above has a template, please paste the template questions below and answer them. (If this pull request is addressing an issue, you can just paste a link to the issue here instead.) -->

<!-- Please ensure your pull request is ready:

- Read the pull request guide (https://eslint.org/docs/developer-guide/contributing/pull-requests)
- Include tests for this change
- Update documentation for this change (if appropriate)

-->

<!-- The following is required for all pull requests: -->

What changes did you make? (Give an overview)

Clarifies that a package.json file is necessary to use --init in the Getting Started guide. (it errors currently when there is no package.json file present)

Is there anything you'd like reviewers to focus on?

Is this clear enough?

<!-- Thank you for contributing!

ESLint adheres to the [JS Foundation Code of Conduct](https://js.foundation/community/code-of-conduct).

-->

Prerequisites checklist

• [ ] I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[x] Documentation update [ ] Bug fix (template) [ ] New rule (template) [ ] Changes an existing rule (template) [ ] Add autofixing to a rule [ ] Add a CLI option [ ] Add something to the core [ ] Other, please explain:

<!-- If the item you've checked above has a template, please paste the template questions below and answer them. (If this pull request is addressing an issue, you can just paste a link to the issue here instead.) -->

<!-- Please ensure your pull request is ready:

- Read the pull request guide (https://eslint.org/docs/developer-guide/contributing/pull-requests)
- Include tests for this change
- Update documentation for this change (if appropriate)

-->

<!-- The following is required for all pull requests: -->

What changes did you make? (Give an overview)

Added a question to the faq answering some of problems in #10618, which I've recently come across myself. I just need a bit of linting for some javascript and don't want a big node.js setup. I figured providing people with a way to make a quick .eslintrc would be a good idea. Even better would be for Eslint to have that thing called defaults and work out of the box.

Is there anything you'd like reviewers to focus on?

Not really. I'm just making this for my own reference and trying my luck at helping others with the same problem I had.

<!-- Thank you for contributing!

ESLint adheres to the [JS Foundation Code of Conduct](https://js.foundation/community/code-of-conduct).

-->

Prerequisites checklist

• [x] I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

• [ ] Documentation update
• [ ] Bug fix (template)
• [ ] New rule (template)
• [ ] Changes an existing rule (template)
• [ ] Add autofixing to a rule
• [ ] Add a CLI option
• [x] Add something to the core
• [ ] Other, please explain:

<!-- If the item you've checked above has a template, please paste the template questions below and answer them. (If this pull request is addressing an issue, you can just paste a link to the issue here instead.) -->

<!-- Please ensure your pull request is ready:

- Read the pull request guide (https://eslint.org/docs/developer-guide/contributing/pull-requests)
- Include tests for this change
- Update documentation for this change (if appropriate)

-->

<!-- The following is required for all pull requests: -->

What changes did you make? (Give an overview)

Cal ESLint only on first CI job to reduce unnecessary servers work (e.g., reduce carbon footprint by unnecessary work).

I added ci-job-number. It returns the job numbers and supports many different CI services. For the second and rest jobs, I print warning (with a note of how to disable this behavior) and exit.

The context behind these changes

@pwithnall in his recent talk suggested thinking more about how our open source projects affect the environment. I found an interesting problem with ESLint and how people are using ESLint on CI.

node_js:
  - node
  - "12"
  - "10"
  - "8"
  - "6"

Here is a Travis CI of my PostCSS. Like many other projects, we many jobs to run tests on all actual Node.js versions. In every job we call npm test:

    "test": "eslint . && jest"

As a result, we call ESLint for every Node.js version. But since ESLint provides static analysis, ESLint output will be the same for all Node.js versions. As a result, we have 2-4 unnecessary ESLint calls for all commits for all open source projects with multiple Node.js versions in .travis.yml.

Is there anything you'd like reviewers to focus on?

Is it a real problem?

• For postcss/postcss every ESLint takes 9 seconds of CPU time.
• For postcss/postcss we have around 250 commits per year.
• Let’s count that we have 4 Node.js versions on Travis CI (we had five versions before and now only 3).
• 1 hour of CPU work gives around 1.7 grams of CO2.
• 9000 seconds of unnecessary CPU time = 42.5 grams of CO2 per year just for one open-source project.
• ESLint is used in >3 000 000 projects. Let’s assume that 75% of them are dead (of course, it is not fair to use PostCSS’s CPU/jobs/time statistics, so I took a bigger number for dead projects and didn’t count non-GitHub projects).
• We can expect that adding this commit could prevent 31 875 Kg of CO2 per year. But please double-check my math or even find a better statistics.

Does somebody already do like this?

• There is eslint-ci by @JLHwung, which already adds ci-job-number to ESLint. I use eslint-ci in all my open-source projects (including PostCSS, Autoprefoxer, and Browserslist). There are also >200 projects, which use eslint-ci too.
• I use ci-job-number in my size-limit and check-dts.
• spech, spelling check tool, also uses ci-job-number.

Why do we need this commit if we have eslint-ci?

People think about Travis CI as a free resource (which is not true). It is hard to convince people to avoid spending free resources if they think resources are free for them personally.

GitHub Actions can be tricky, and jobs can be used not only for Node.js version.

Yeap, found that GitHub Actions workflows can be very tricky, and jobs can be used not only to test different Node.js versions.

This is why we removed GitHub Actions support from ci-job-number. On GitHub Actions, ESLint will run on every job.

We are collecting feedback and evolving ci-job-number to have predicted results of every CI service.

Thanks everyone, we're not moving forward with this pull request. If anyone would like to submit a tutorial on setting up ESLint in a CI environment (as discussed previously) please feel free.

That's what I'm seeing, too. Removing the OpenJS Foundation logo will help. I'd also like to see "Edit this page" either on a separate line from the icons or have the icons aligned to the right of the page to separate them from "Edit this page" (only on mobile, of course)

Okay, sounds like we are on the right track. I'd suggest updating this RFC with the latest agreements. I think we're close!

Bumps node-fetch from 2.6.0 to 2.6.1. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/bitinn/node-fetch/releases">node-fetch's releases</a>.</em></p> <blockquote> <h2>v2.6.1</h2> <p><strong>This is an important security release. It is strongly recommended to update as soon as possible.</strong></p> <p>See <a href="https://github.com/node-fetch/node-fetch/blob/master/docs/CHANGELOG.md#v261">CHANGELOG</a> for details.</p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/node-fetch/node-fetch/blob/master/docs/CHANGELOG.md">node-fetch's changelog</a>.</em></p> <blockquote> <h2>v2.6.1</h2> <p><strong>This is an important security release. It is strongly recommended to update as soon as possible.</strong></p> <ul> <li>Fix: honor the <code>size</code> option after following a redirect.</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/node-fetch/node-fetch/commit/b5e2e41b2b50bf2997720d6125accaf0dd68c0ab"><code>b5e2e41</code></a> update version number</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/2358a6c2563d1730a0cdaccc197c611949f6a334"><code>2358a6c</code></a> Honor the <code>size</code> option after following a redirect and revert data uri support</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/8c197f8982a238b3c345c64b17bfa92e16b4f7c4"><code>8c197f8</code></a> docs: Fix typos and grammatical errors in README.md (<a href="https://github-redirect.dependabot.com/bitinn/node-fetch/issues/686">#686</a>)</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/1e99050f944ac435fce26a9549eadcc2419a968a"><code>1e99050</code></a> fix: Change error message thrown with redirect mode set to error (<a href="https://github-redirect.dependabot.com/bitinn/node-fetch/issues/653">#653</a>)</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/244e6f63d42025465796e3ca4ce813bf2c31fc5b"><code>244e6f6</code></a> docs: Show backers in README</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/6a5d192034a0f438551dffb6d2d8df2c00921d16"><code>6a5d192</code></a> fix: Properly parse meta tag when parameters are reversed (<a href="https://github-redirect.dependabot.com/bitinn/node-fetch/issues/682">#682</a>)</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/47a24a03eb49a49d81b768892aee10074ed54a91"><code>47a24a0</code></a> chore: Add opencollective badge</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/7b136627c537cb24430b0310638c9177a85acee1"><code>7b13662</code></a> chore: Add funding link</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/5535c2ed478d418969ecfd60c16453462de2a53f"><code>5535c2e</code></a> fix: Check for global.fetch before binding it (<a href="https://github-redirect.dependabot.com/bitinn/node-fetch/issues/674">#674</a>)</li> <li><a href="https://github.com/node-fetch/node-fetch/commit/1d5778ad0d910dbd1584fb407a186f5a0bc1ea22"><code>1d5778a</code></a> docs: Add Discord badge</li> <li>Additional commits viewable in <a href="https://github.com/bitinn/node-fetch/compare/v2.6.0...v2.6.1">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~akepinski">akepinski</a>, a new releaser for node-fetch since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Thanks for the followup from Twitter. I wasn't involved with building out this feature, so I'm not sure if this is even possible, but we'll see what the others think.

This is the promised post about how we are sponsoring our dependencies. It's set to publish on Wednesday.

View Rendered Text

This PR adds Class Property Access Expressions support. The proposal is seeking stage 2 advancement in September meeting.

I think the best two options here are 1) do nothing, or 2) add a header that says “You are viewing documentation for an older version of ESLint. Click here for the most recent version.”

I don’t want to edit the actual content.

Add TSC meeting 10-September-2020 transcript.

This PR is autogenerated by the "Generate Transcript" GitHub Action.

Closing since we did not have a meeting.

@fisker I’d suggest opening a separate issue to discuss your idea.

I think figuring out who knows about how we are using this would be good. :) I don’t feel comfortable merging in my own.

Thanks

The code example in the documentation for eslint.defineParser at https://eslint.org/docs/developer-guide/nodejs-api#linterdefineparser

uses the old "parse" API.

Change to "parseForESLint" to reflect latest ESLint API.

Yes, I am happy to provide a PR.

Thanks. As mentioned in the PR, parse() is still applicable and parseForESLint() is only there for when people want to provide additional functionality that is specific to Eslint.

Thanks for the suggestion. It's not required for parsers to use parseForESLint(), which is why it's not included in this page. We use parse() if parseForESLint() is not present.

This is the promised post about how we are sponsoring our dependencies. It's set to publish on Wednesday.

Are linter and CLIEngine used outside of auto config?

This looks like a good first pass. Please take a look at https://deploy-preview-783--eslint.netlify.app/, which previews the site with the change. It looks like the changes are a bit jumbled on mobile. Can you take a look?

Thanks for taking a look at this. If you could please take a look at adding the email you used for this commit, we need to get the CLA signature correct.

If you go through --init now, you get to a point where it asks if you want us to examine the source code files to determine the correct config to use. That's called autoconfig. Most of the functionality is in lib/init/autoconfig.js, so it would just be a matter of removing that file and then removing the associated question that triggers it.

Awesome, we are happy to have the help! Hopefully the setup instructions are clear enough, but let us know if you need any help getting started.