Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New: add a defineParser function #9321

Merged
merged 5 commits into from Nov 26, 2017

Conversation

CompuIves
Copy link
Contributor

@CompuIves CompuIves commented Sep 17, 2017

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

[x] 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:

What changes did you make? (Give an overview)

I added an defineParser function to the Node API, which allows you to define a custom parser that eslint will use when defined in the config.

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

I'm not sure if the implementation is desired, returning the error object for errors doesn't feel right. I'm also not sure if I added enough tests.

Copy link
Member

@platinumazure platinumazure left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left one question, thanks for contributing!

lib/parsers.js Outdated
const parser = this._parsers[parserId];

if (!parser) {
return require(parserId);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should require(parserId) be cached into the parser map in this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, node already caches requires by default (https://nodejs.org/api/modules.html#modules_require_cache), but I could add it for explicitness.

Copy link
Member

@not-an-aardvark not-an-aardvark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! I left a few suggestions.

@@ -241,6 +241,26 @@ Map {
*/
```

### Linter#defineParser

Each instance of `Linter` holds a map of custom parsers. If you want to define a parser programmaticaly you can add this function
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The word "programmatically" is spelled incorrectly here.

}
});

const results = linter.verify("// some source text", { parser: 'my-custom-parser' });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: For consistency, can you use double quotes for "my-custom-parser"?

lib/parsers.js Outdated
// Public Interface
//------------------------------------------------------------------------------

class Parsers {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having a separate module for this isn't necessary given that a regular Map basically does the same thing (aside from using require). Instead, I think this could just be included as part of the defineParser method. However, I don't really have a strong objection to doing it like this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. This feels like a pretty generic store - I think it would actually be clearer to use a Map as well.

lib/linter.js Outdated
@@ -727,6 +709,7 @@ module.exports = class Linter {
this.version = pkg.version;

this.rules = new Rules();
this.parsers = new Parsers();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you prefix this property name with an underscore? (this._parsers)

* @param {any} parserModule The parser object
* @returns {void}
*/
defineParser(parserId, parserModule) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add tests for defineParser?

@not-an-aardvark not-an-aardvark added accepted There is consensus among the team that this change meets the criteria for inclusion core Relates to ESLint's core APIs and features enhancement This change enhances an existing feature of ESLint labels Sep 18, 2017
@not-an-aardvark not-an-aardvark added this to In Progress in Core Roadmap Sep 19, 2017
@eslintbot
Copy link

LGTM

Copy link
Member

@not-an-aardvark not-an-aardvark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me aside from a few documentation nitpicks. Thanks!

### Linter#defineParser

Each instance of `Linter` holds a map of custom parsers. If you want to define a parser programmatically you can add this function
with the name of the parser as first argument and the parser object (having either `parseForESLint` or `parse` as keys) as second argument.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be good to link to the parser documentation here. For example:

...with the name of the parser as the first argument and the [parser object](/docs/developer-guide/working-with-plugins#working-with-custom-parsers) as the second argument.

Each instance of `Linter` holds a map of custom parsers. If you want to define a parser programmatically you can add this function
with the name of the parser as first argument and the parser object (having either `parseForESLint` or `parse` as keys) as second argument.

If during linting the parser is not found it will fallback to `require(parserId)`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: I think a comma should be added after the word "found".

@eslintbot
Copy link

LGTM

@CompuIves
Copy link
Contributor Author

Good feedback! I committed the suggested changes.

Copy link
Member

@kaicataldo kaicataldo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this!

lib/parsers.js Outdated
// Public Interface
//------------------------------------------------------------------------------

class Parsers {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. This feels like a pretty generic store - I think it would actually be clearer to use a Map as well.

@kaicataldo
Copy link
Member

@CompuIves Friendly ping.

@CompuIves
Copy link
Contributor Author

CompuIves commented Oct 31, 2017

Sorry for the delayed reply, I got caught up in some work. I just pushed a commit that moves the _parsers property to a Map.

@jsf-clabot
Copy link

jsf-clabot commented Nov 5, 2017

CLA assistant check
All committers have signed the CLA.

@bruno12mota
Copy link

@CompuIves great work on this! Would be awesome to merge this and get a release going since it's been some time and having this as a git dependency will collide with other eslint dep in some cases.

Copy link
Member

@platinumazure platinumazure left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

@not-an-aardvark not-an-aardvark merged commit 28c9c8e into eslint:master Nov 26, 2017
@not-an-aardvark
Copy link
Member

Thanks for contributing!

@not-an-aardvark not-an-aardvark moved this from In Progress to Done in Core Roadmap Jan 25, 2018
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators May 26, 2018
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label May 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion core Relates to ESLint's core APIs and features enhancement This change enhances an existing feature of ESLint
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

9 participants