Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Allow registering parsers with Node.js API

See original GitHub issue

The version of ESLint you are using. 7.9.0

The problem you want to solve. When using the ESLint class, it is possible to directly specify options.plugins. These plugins then get stored in the additionalPluginPool map inside that ESLint instance (src). When loading a plugin, if it is found in the additionalPluginPool, it does not trigger the ModuleResolver (src). This provides the ability to bundle this code in a such a way that does not rely on eslint’s internal module resolution.

However, no such additional pool exists for parsers. When loading a parser, it immediately triggers the ModuleResolver (src). Therefore, it appears that there is no way to use custom parsers in ESLint without relying on the internal ModuleResolver.

Your take on the correct solution to problem. Apply the same strategy used for plugins to parsers. Create a new, optional parsers property on ESLint.Options that would populate an additionalParserPool map. Then on parser load, check this additionalParserPool before moving to module resolution.

Are you willing to submit a pull request to implement this change? Yes, but I’d have to check with my current employer first in regards to the CLA.

Issue Analytics

State:
Created 3 years ago
Comments:7 (4 by maintainers)

Top GitHub Comments

2reactions

molisanicommented, Sep 17, 2020

There are cli tools like standard and xo that use ESLint and plugins as runtime dependencies. I’m not sure if there are tools that successfully bundle them instead.

After looking through xo it appears that they use require.resolve (src) to pull in parser dependencies. I believe that webpack (for example) supports bundling static usage of require.resolve so that should work. With that workaround I’ll close this out. Thanks @mdjermanovic and @nzakas for the information and insight!

0reactions

nzakascommented, Sep 17, 2020

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

Top Results From Across the Web

REST API Login and Register Node.js with JWT - Medium

In this discussion, we will create a REST API Login and Register using Node.js with JWT. And I will give some examples to...

User Registration RESTful API Using Node.js And Express 4

Let us see how to create RESTful APIs for user registration using Node.js and Express. Using Node Express we can easily manage GET,...

Node.js and Express Tutorial: Building and Securing RESTful ...

How to easily develop and build RESTful APIs with Node.js and Express, while securing it with Auth0. Build a demo that allows third-party ......

How to Build a Secure Node js REST API: 4 Easy Steps

This blog aims at teaching you about the steps required to build a secure Node js REST API from scratch in detail.

URL | Node.js v19.3.0 Documentation

Parsing the URL string using the WHATWG API: ... let myURL = new URL('http://Example.com/', 'https://example.org/'); // http://example.com/ myURL = new ...