Caveat -- we've "solved this" specifically in a way that works in our playground. This isn't a good way to solve this or even a scalable way to solve it -- much of the "solving" involves us purely mocking out any of our internals that touch NodeJS APIs.

One of the reasons we hack around like this is because we have all the tabs on our playground to allow us to inspect our internals and TS's internals.

What we've done is by far NOT what should be done by others. Instead one should be looking to more holistically mock out the NodeJS APIs themselves so that all of the ESLint ecosystem can "just work". For example this is what you will see "VSCode Web" or "Code Sandbox" or other such browser IDEs do.

In an ideal world -- yeah, this is something we could consider to make it easy for people to embed our tooling without any effort. But in our current state I just don't we don't have the bandwidth to consider taking on such a workload.

Thoughts @typescript-eslint/triage-team

@bradzacher Thanks for the feedback, its clear and I respect completely your bandwidth. Your giving a sense of magnitude of doing this "properly" is also useful!

For example this is what you will see "VSCode Web" or "Code Sandbox" or other such browser IDEs do.

Good point, they've apparently also crossed this bridge.

Overall, I did and continue to wonder why ESLint went down a path of being coupled to Node APIs, like TS has done which is even more complex of a tool.

why ESLint went down a path of being coupled to Node APIs

Well, they have two areas of APIs:

• ESLint: relies on Node.js APIs; tailored to the file system use case
• Linter: doesn't rely on any Node.js APIs or filesystem operations; tailored to the browser use case

like TS has done which

TypeScript also abstracts away system APIs. It runs well on Node.js by default but can be made to run fully virtually: https://www.typescriptlang.org/dev/typescript-vfs.

We've been interested in moving to that VFS for tests for a while: #1891

The problem with decoupling from nodejs APIs is that often means that you can't use 3rd party dependencies for things and instead have to write your own code or fork something.

For example we rely on a 3rd party dependency to do globbing - which requires the node FS API to iterate the disk.

This sort of behaviour falls over when you move to the browser - what does it mean to "glob the file system" if there is no file system? Browser IDEs usually have a VFS which allows them to create and maintain the folder structure - and in using a VFS they also usually reimplement the node FS API.

Ultimately though it depends on usecases and cost/value trade-offs. If 99.99% of usecases are in a NodeJS-like environment - then spending time making the code nodejs agnostic isn't hugely valuable.

Is there a proposal to ESLint to make them web-compatible, to the extent of having a reusable ESLint playground that you can attach plugins to? I think we shouldn't concern us about infra more than a typical ESLint plugin should do.

Indeed, this isn't something we're in a good place to support. If you're interested in taking this on then I think the right next steps would be #1891 to prove out running typed linting in a VFS.

But, regardless of how that goes, we definitely don't have the bandwidth to set up an ESLint VFS + browser solution ourselves (as much as we would love to!). That task would just be something we could give advice to if you want to ask us in our Discord / ping us on an ESLint RFC.

Thanks for asking! Closing out as out-of-scope for typescript-eslint itself.

Thanks for the thoughtful responses all!