Using ESlint in the browser

[abhishiv]

Hey guys, I'm aware that the eslint team didn't set out to target browser, but since it has a long time since that decision was made, and the ecosystem has changed a lot, have you thought about reconsidering it?

In the case of this issue for example, it seems a lot of people are maintaining their custom forks to mitigate this issue, and to run eslint in the browser. For example see the comment by @finom in #2585

It seems it would be a simple fix to make eslint compatible with webpack/browserify. Would you be willing to accept a PR with this fix?

[ilyavolodin]

I'm not sure that would be a good idea. Problem with doing this, is that we will now have to support browser version of ESLint as well as Node. I'm not sure the team has cycles to support something like that. Also, outside of online editors, I'm not sure what would be the use-case for doing it.

[abhishiv]

Hey @ilyavolodin

Yeah my use case is related to online editors. I would also argue that this use case is growing by the day. Actually if you look at most online editors, they lack linting because of this eslint can't run in the browsers or maintain their own forks. I know Orion by eclipse maintains their own internal fork of eslint for example.

If the eslint team doesn't have resources to actively support browser, maybe you can get around it by communicating it strongly? Just making sure that eslint builds under webpack without forking would be a big relief for many people.

[ilyavolodin]

@abhishiv Just to clarify, ESLint in it's current for does run in the browser (it runs on ESLint.org site), but it's not compatible with Webpack, just with Browserify. I have no strong preference either way, although when this project was created it was clearly specified that we are not planning on supporting anything other then Node. I will add TSC agenda label, and we can discuss this on the next TSC meeting.

[ilyavolodin]

TSC Summary: Number of online editors is growing, and they do not have a good way to support ESLint, since we don't officially support browser environments. While we do have a build script to browserify ESLint, it's not possible to use Webpack to package ESLint for browsers without changes.

TSC Question: Should we support browsers (and Webpack)? If so, should we make it very clear that it's a low priority for our team, and fixes will only going to be done if somebody outside of the team will submit PRs against them?

[mysticatea]

I'd like to put one note here.
The official browser support will make a commit that we never use file system in core rules in future.

[btmills]

The TSC discussed this in the 2017-04-13 meeting and was generally open to the idea of supporting running ESLint in the browser. This can be discussed in a future meeting once we know more about what changes would be needed.

[abhishiv]

Awesome news! Can't wait to see eslint running in the browser.

if I can summarise the changes needed are

1. load-rules.js: don't load rules in a dynamic way

fs.readdirSync(rulesDir).forEach(file => {
        if (path.extname(file) !== ".js") {
            return;
        }
        rules[file.slice(0, -3)] = path.join(rulesDir, file);
});

That's the only change needed as far as I can see.

[not-an-aardvark]

@eslint/eslint-team ping -- Is this something we want to support? It seems like a simple change that would help a lot of users.

[not-an-aardvark]

TSC Summary: This issue proposes adding official support for running ESLint in a browser. It seems like only a small change would be needed for this to work.
TSC Question: Should we accept this issue?

[nzakas]

I'm not a fan of this. Even though it's a small change code-wise, it could lead to a lot more issues being filed for browser support and bugs. I think the maintenance burden is pretty high.

If making a small code change could make it easier for others to use in the browser, I'd be for making the change with the explicit note that we do not officially support ESLint in browsers, so it's a "buyer beware" situation going forward.

[btmills]

@nzakas we came to the same conclusion in today's TSC meeting.

The TSC is wary of potential rabbit holes that officially supporting the browser could lead to, so we won't be officially supporting it. However, we'll still consider accepting individual code changes that make it easier to run in the browser as long as they're small and don't have an adverse impact.