eslint / espree

An Esprima-compatible JavaScript parser

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

espree's Issues

jQuery Foundation adopts Esprima

So, this happened:
http://blog.jquery.com/2015/01/26/jquery-foundation-adopts-esprima/

How does this affect the Espree project? Are pull requests against Esprima more likely to be merged? Is it worth reaching out to the Esprima project to try to coordinate a merge?

Is Espree to Esprima as io.js is to node.js?

Spread operator should be allowed anywhere in array literals and function calls

Those statements should be valid:

var a = [...b, 1];
foo(...a, b, ...c);

Right now, running eslint on code like this gives me error Spread must be the final element of an element list and as it is a syntax error, it does not lint the file.

See MDN

Implement unicode code point escapes

Support unicode escapes of any number of characters. ex: \u{0}, \u{abcdef123456789}

Lost contributions?

This repository README states: "Espree starts as a fork of Esprima v1.2.2". However, all of history of Esprima up to this point have been conflated into one initial commit. It seems it would be more fair to Esprima contributors to preserve the history.

Support ES6 modules (import+export declarations)

Refs #10. Esprima harmony already supports this.

support destructured params w/defaults (shorthand syntax)

While support for destructuring was added in #51 none of these cases work:

• function a({x = 10}) {}
• function a({x = 10, y: { z = 10 }}) {}
• ({x = 10}) => x
• ({x = 10, y: { z = 10 }}) => [x,y]
• [a=10] = 0
• var {a = 10} = {}

Latest spec can be found here:
estree/estree#13

Update ClassDeclaration/ClassExpression name -> ID

Esprima incorrectly implemented ClassDeclaration and ClassExpression, and since I copied that, we have the same problem. The issue is that ESTree specified the name of a class as id while we are using name. So, we need to switch to use id instead.

Implement JSX syntax

Add support for JSX syntax. This should be done in the same form as esprima-fb.

Template string tokens are strange

The way that template string tokens are generated is pretty strange. This code:

var foo = `hi${bar}`;

Is tokenized as:

[
    {
        "type": "Keyword",
        "value": "var"
    },
    {
        "type": "Identifier",
        "value": "foo"
    },
    {
        "type": "Punctuator",
        "value": "="
    },
    {
        "value": "`hi${"
    },
    {
        "type": "Identifier",
        "value": "bar"
    },
    {
        "type": "Punctuator",
        "value": "}"
    },
    {
        "type": "Punctuator",
        "value": ";"
    }
]

So the first part of the template string is represented by a token without a type, and then the rest are just regular tokens, completely losing the end of the template string.

Add ECMAScript version filter

This feature allows an extra ecmascript option to be passed to the parse() method. This determines the syntax will be accepted by the parser. The default is all syntax (similar to Esprima) and the valid values are currently 5 and 6.

To test, it's easiest to use let and const. Espree already parses them but technically these are not allowed in ECMAScript 5. So when ecmascript is 5, using let and const should throw an error.

Allow return in global scope

For Node.js compatibility, it would be good to add the option to use return in the global scope.

Working on this now.

Template Strings should disallow Legacy Octal Literals

See mikesherov/esprima@e7f1d03

as defined in: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-template-literal-lexical-components the note says:

A conforming implementation must not use the extended definition of EscapeSequence described in B.1.2 when parsing a TemplateCharacter.

create-test / default-params issue

1. the placeholder for empty defaults array members should possibly be undefined instead of null
2. create-test-.js improperly changes undefined array members to null.

Recently when working on defaultParams and destructuring I noticed that I was having some mismatches with Esprima on the expected output, especially involving the placeholder when there are not defaults specified for each parameter.

When I use create-test to generate the expected output it seems to show [null, 1] for function(a, b=1){}, but when i actually console.log the output from Esprima, it looks like [undefined, 1].

Here is I think the source of the issue:

The only thing that makes me unsure is that the single test in esprima also shows null as the placeholder, but I can only assume they're using JSON.stringify in their tests, because Esprima will not generate that output:
https://github.com/jquery/esprima/blob/harmony/test/harmonytest.js#L2612

Let me know if you have any ideas otherwise I'll like manually change the tests to use undefined as part of #51, which changed some of the code around this area and caused me to bump into this issue.

Website design

We need a website to post Espree documentation and a demo. It would be nice if it had the same visual language as the eslint.org, but I don't think that's 100% necessary.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Lines are calculated wrong when relying on ASI

Given the following example:

a()

gives the following loc for the Programm AST node:

"loc": {
    "start": {
        "line": 1,
        "column": 0
    },
    "end": {
        "line": 1,
        "column": 3
    }
}

if you have an extra line break

a()

you get the following loc:

"loc": {
    "start": {
        "line": 1,
        "column": 0
    },
    "end": {
        "line": 2,
        "column": 0
    }
}

Each extra line will increase loc.end.line

a()

"loc": {
    "start": {
        "line": 1,
        "column": 0
    },
    "end": {
        "line": 8,
        "column": 0
    }
}

But if you use a semicolon after the CallExpression you will get a different loc for Program even if you have multiple empty lines:

a();

"loc": {
    "start": {
        "line": 1,
        "column": 0
    },
    "end": {
        "line": 1,
        "column": 4
    }
}

Empty paren in expression throws TypeError

The following example crashes eslint (caused by the last line in the file):

var left, aSize, bSize;

aSize = {
  width: 800,
  height: 600
};

bSize = {
  width: 200,
  height: 100
};

left = (aSize.width/2) - ()

with error

eslint test.js

/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/token-store.js:181
            starts[right.range[0]] + padding
                              ^
TypeError: Cannot read property '0' of undefined
    at EventEmitter.api.getTokensBetween (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/token-store.js:181:31)
    at RuleContext.(anonymous function) [as getTokensBetween] (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/rule-context.js:82:33)
    at isSpaced (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/rules/space-infix-ops.js:21:34)
    at EventEmitter.checkBinary (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/rules/space-infix-ops.js:40:14)
    at EventEmitter.emit (events.js:117:20)
    at Controller.controller.traverse.enter (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/eslint.js:673:25)
    at Controller.__execute (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/node_modules/estraverse/estraverse.js:397:31)
    at Controller.traverse (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/node_modules/estraverse/estraverse.js:495:28)
    at EventEmitter.module.exports.api.verify (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/eslint.js:666:24)
    at processFile (/home/julien/.nvm/v0.10.30/lib/node_modules/eslint/lib/cli-engine.js:172:27)

Looks like parentheses in the end of the line left = (aSize.width / 2) - () treated as ArrowParameterPlaceHolder

https://www.dropbox.com/s/0oltkd0vbdo0iew/Screenshot%202015-02-10%2018.51.52.png?dl=0

eslint/eslint#1816
AtomLinter/linter-eslint#28

Update module functionality

• add test to validate that sourceType="module" effectible enables strict mode (e.g.: WithStatement is invalid in modules)
• ImportDeclaration and ExportDeclaration cannot be used inside functions (missing tests and implementation)
• Enable classes for export and export default declarations (all TODOs are in the code, very straight forward)

Support test fixtures for when feature = false does not result in an error

For Unicode code point escapes, the string values are still valid JavaScript regardless of the feature state. But the test runner is hard-coded to check for a thrown error if the features is set to off. Thus, I'm unable to write passing tests for this feature.

A few ideas:

1. Add an option to *.config.js to skip this second test
2. Remove the test entirely, since I'm not sure how valuable it is to us (checking that new features aren't backwards compatible).

@nzakas thoughts?

Add ECMAScript 6 features

This is a rollup that will let us keep track of ES6 progress.

• let declarations
• const declarations
• Regular expression u flag
• Regular expression y flag
• Binary literals
• New octal literals
• Arrow functions
• Default parameters
• Rest parameters
• Spread operator
• super references
• Classes
• for-of loops
• Generators
• Object literal property shorthand
• Object literal method shorthand
• Object literal computed properties
• Template strings
• Destructuring
• Unicode code point escapes
• Allow duplicate object literal properties (except __proto__)
• Modules

Template string variables in JSX raises "Unexpected token ILLEGAL"

This is a regression from espree 0.12.0.

var espree = require('espree');

espree.parse('<foo bar={`${baz}`} />', {
    ecmaFeatures: {
        templateStrings: true,
        jsx: true
    }
});
// Raises: Unexpected token ILLEGAL

The same code without ${baz} is OK

Remove TryStatement.handlers

Ref estree/estree#1:

interface TryStatement <: Statement {
    // ....
    handler: CatchClause | null;
    handlers: [ CatchClause ]; // Removed
    // ....
}

The handlers array on TryStatement nodes was replaced with a single handler, which may be either a CatchClause or null.
#70 added support for the singular handler property. The next step is to remove handlers. This will be a breaking change.

Support TryStatement.handler

Ref estree/estree#1:

interface TryStatement <: Statement {
    // ....
    handler: CatchClause | null;
    handlers: [ CatchClause ]; // Removed
    // ....
}

The handlers array on TryStatement nodes was replaced with a single handler, which may be either a CatchClause or null.

Presumably the best way to do this is to port jquery/esprima#1034, a backward-compatible change which adds handler and preserves handlers, then remove handlers as a breaking change later?

Parser fails on generator methods

Espree parser fails on the following with Unexpected token *:

class Foo {
  *bar() {
  }
}

Test case:

var espree = require("espree");

espree.parse('class Foo {*bar() {}}', {
  "ecmaFeatures": {
    "classes": true,
    "generators": true,
    "objectLiteralShorthandMethods": true,
  },
});

Stack:

node_modules/espree/espree.js:5373
        throw e;
              ^
Error: Line 1: Unexpected token *
    at throwError (node_modules/espree/espree.js:2078:17)
    at throwUnexpected (node_modules/espree/espree.js:2141:5)
    at parseObjectPropertyKey (node_modules/espree/espree.js:2364:5)
    at parseClassBody (node_modules/espree/espree.js:4934:15)
    at parseClassDeclaration (node_modules/espree/espree.js:5023:17)
    at parseSourceElement (node_modules/espree/espree.js:5053:28)
    at parseSourceElements (node_modules/espree/espree.js:5101:25)
    at parseProgram (node_modules/espree/espree.js:5120:12)
    at Object.parse (node_modules/espree/espree.js:5361:19)
    at Object.<anonymous> (esp.js:3:8)

See eslint/eslint#1990.

Switching location tracking

Espree is currently using the old mark() and markEnd() methods to track location (from Esprima 1.2.2). Esprima Harmony has two new methods markerCreate() and markerApply(). Before we can merge over more complex features, we need to switch location tracking to what's in Harmony.

String identifiers can't be used with method shorthand

The following should be legal but throws an error when objectLiteralShorthandMethods is enabled:

var x = {
    "foo"() {
        return bar;
    }
};

`[[[{a=0}]]]` should not parse

Currently it is parsed as an expression with an AssignmentPattern in it.

Esprima 2.0 is out

As I know, espree is a fork of Esprima with improvements of es6 support, so Esprima 2.0 is out with a bunch of es6 improvements, look it (Also it was moved to jquery org. https://github.com/jquery/esprima/)

lexical binding updated from Esprima

See jquery/esprima#1076

Is there a reason why you don't contribute to esprima-fb

Like the title says, wouldn't it be good to contribute to esprima-fb?

Or are there any reasons why you can't do this?

For loops allow let even with blockBindings is false

Currently, for loops (for, for-in, for-of) all allow let to be used even when blockBindings is set to false. So this works fine:

for (let x of y) {
}

With this config:

{
    blockBindings: false,
    forOf: true
}

This should throw an error instead.

ES6: Parse "u" and "y" flags for regular expressions

ECMAScript 6 adds two extra flags to regular expressions, u and y. We should be able to add those as valid options in ES6 and edge modes.

Additional 3rd Party Scripts

Here are a few ES6-based projects to consider adding to the 3rd party dir once we get module support:
https://github.com/facebook/immutable-js
https://github.com/emberjs/ember.js
https://github.com/babel/babel

So excited this is landing soon!

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Shorthand property named "get" fails to parse

var espree = require('espree');

espree.parse('var a = {get};', {
    ecmaFeatures: {
        objectLiteralShorthandProperties: true
    }
});

Raises Error: Line 1: Unexpected token }

Rename get to anything else, and it works.

Object literal shorthand generator methods have incorrect range

Perhaps this is intentional, but the range given to object literal shorthand generator methods includes only the method body {}. Since they key is part of the parent property and overlapping, non-ancestral ranges might get confusing, I'm not sure that the FunctionExpression's range should include all of *foo(arg1) {}, but it seems like the range should expand to at least (arg1) {}.

Related: eslint/eslint#1677

//test.js
var inspect = require('util').inspect,
    espree = require('espree');

var source = [
    "({",
    "    *foo(arg1) {}",
    "})"
].join("\n");

var ast = espree.parse(source, {
    range: true,
    tokens: true,
    ecmaFeatures: {
        generators: true,
        objectLiteralShorthandMethods: true
    }
});

console.log(inspect(ast.body[0].expression.properties[0]));
console.log(inspect(ast.body[0].expression.properties[0].value.params[0]));
console.log(inspect(ast.tokens));

$  node test.js
{ type: 'Property',
  key: { type: 'Identifier', name: 'foo', range: [ 8, 11 ] },
  value:
   { type: 'FunctionExpression',
     id: null,
     params: [ [Object] ],
     defaults: [],
     body: { type: 'BlockStatement', body: [], range: [Object] },
     rest: null,
     generator: true,
     expression: false,
     range: [ 18, 20 ] },
  kind: 'init',
  method: true,
  shorthand: false,
  computed: false,
  range: [ 7, 20 ] }
{ type: 'Identifier', name: 'arg1', range: [ 12, 16 ] }
[ { type: 'Punctuator', value: '(', range: [ 0, 1 ] },
  { type: 'Punctuator', value: '{', range: [ 1, 2 ] },
  { type: 'Punctuator', value: '*', range: [ 7, 8 ] },
  { type: 'Identifier', value: 'foo', range: [ 8, 11 ] },
  { type: 'Punctuator', value: '(', range: [ 11, 12 ] },
  { type: 'Identifier', value: 'arg1', range: [ 12, 16 ] },
  { type: 'Punctuator', value: ')', range: [ 16, 17 ] },
  { type: 'Punctuator', value: '{', range: [ 18, 19 ] },
  { type: 'Punctuator', value: '}', range: [ 19, 20 ] },
  { type: 'Punctuator', value: '}', range: [ 21, 22 ] },
  { type: 'Punctuator', value: ')', range: [ 22, 23 ] } ]

Edit: Add arg1 to output.

const inside switch case statement is a syntax error

From eslint/eslint#1805

Maybe a bug with ES 6 block bindings?

$ eslint -v
v0.14.1


$ eslint -c .eslintrc test.js 

test.js
  4:7  error  Unexpected token const

✖ 1 problem (1 error, 0 warnings)


$ cat test.js 
function fn(foo) {
  switch (foo) {
    case "foo":
      const bar = "bar";
      break;
  }
}


$ cat .eslintrc 
env:
  browser: true,
  node: true

ecmaFeatures:
  blockBindings: true

---

Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

Logo design

We need a nice logo to represent Espree on the interwebs. Any and all help welcome.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Phase 1

Phase 1 is all about setting up the repository in such a way that it's easier to make changes later on.

• Split up espree.js into as many small files as possible and place those small files in lib/
• Change over build system to use ShellJS
• Convert standalone build scripts into ShellJS
• Create Mocha tests for small files
• Upgrade ESLint and change code to match ESLint project styles
• Create browserify build step for a browser-compatible version of espree.js

When ecmaFeatures.forOf is true, check for operator is "undefined" when match keyword is "in"

Enable forOf

{ forOf: true }

Espree will error with "undefined"

for (var k in console) {
    doSomething();
}

See test files in PR for examples.

Missing files in npm package

Espree is missing the lib/ directory in the npm package.

Features as modules

In the README you say you're going to break the code base down into smaller files in a CommonJS pattern. Would it be possible to make it so that features are not dependent on one another. So say you don't care about parsing comments the comment module doesn't need to get loaded or included.

Thinking about this because I have a library where I want to use Esprima (or any proper code parser) instead of hacky regular expressions but the size of the libraries are just too large. Being able to shrink it down to just what I need could solve my issue.

Classes are allowed in modules even when classes feature flag is disabled

Right now, enabling ecmaFeatures.modules means that classes can be default exported:

export default class Foo {}

This should throw an error if ecmaFeatures.classes is false.

Update template literal parsing

@mikesherov further improved upon what we have for Esprima, so best to port those changes in:

jquery/esprima#1104

Ensure FunctionDeclaration is used for module exports

For this case:

export default function() {}

The function should be represented with a FunctionDeclaration node with null id, but is currently represented by a FunctionExpression node.

What's up with the `extra` object?

Trying to wrap my head around the extra object, which seems to be used everywhere for everything. Is it just a combination of parsing options & parsing state?

Error for "missing argument in class setters" fails to format

Using espree master, this code :

espree.parse('class A { set foo(){} }', { ecmaFeatures: { classes: true }});

Throws :

Error: ASSERT: Message reference must be in range
    at assert (/home/ubuntu/workspace/espree.js:78:15)
    at /home/ubuntu/workspace/espree.js:2083:17
    at String.replace (native)
    at throwError (/home/ubuntu/workspace/espree.js:2080:29)
    at throwErrorTolerant (/home/ubuntu/workspace/espree.js:2106:20)
    at tryParseMethodDefinition (/home/ubuntu/workspace/espree.js:2438:17)
    at parseClassBody (/home/ubuntu/workspace/espree.js:4984:22)
    at parseClassDeclaration (/home/ubuntu/workspace/espree.js:5065:17)
    at parseSourceElement (/home/ubuntu/workspace/espree.js:5095:28)
    at parseSourceElements (/home/ubuntu/workspace/espree.js:5143:25)

I think tryParseMethodDefinition L2438 should be throwErrorTolerant(lookahead, Messages.UnexpectedToken, lookahead.value);

Trailing comments lost with return and debugger statements

I noticed that ReturnStatement nodes doesn’t have leadingComments and trailingComments attached in some cases.

The following code example fails and doen’t have leadingComments or trailingComments:

function a() {
    /* before */
    return;
    /* after */
}

The following code examples work:

Without ReturnStatement:

function a() {
    /* before */
    b();
    /* after */
}

Only one leading comment:

function a() {
    /* before */
    return;
}

Only one trailing comment:

function a() {
    return;
    /* after */
}

Same problem with the debugger statement.

Esprima bug: https://code.google.com/p/esprima/issues/detail?id=609

super should be allowed in classes by default

Right now, I need to enable classes and superInFunctions in order to use super() in a class. Classes should always be allowed to use super regardless of the superInFunctions flag.

Add sourceType to Program node

Per ESTree: Program nodes now will have sourceType property of module or `script'.

Destructured catch clause doesn't work

Given the following snippet, with ESLint I get an error on the catch line with Unexpected token {

function x({a}) {
  try {
    const {b} = a;
  }
  catch({stack}) {
  }
}

Change rest parameters to implement ESTree

Rest parameters should now end up in a RestElement in a function's params array (see https://github.com/estree/estree/blob/master/es6.md#restelement). This would involve removing the rest property from all function types and would be a breaking change.