Hi David, I think that's a good summary of what the consensus is. I would add that the implementation could be as simple as adding a new method onto CLIEngine, but I think we're all open to whatever makes sense. We obviously need the current sync version of the methods to continue to work for all of consumers of the current API, but otherwise, the options are wide open.
There's some useful prior art here: https://github.com/pinterest/esprint It looks like Pinterest might not be maintaining this anymore, though the fact that it exists might indicate we don't need dramatic changes inside of ESLint to get something similar working. We would probably want to trigger this feature using a CLI flag initially, so people can opt-in to the experience while we're early in development. At a later point we'll be able to determine if it makes sense to run as the default (possibly based on some heuristic like number of files to lint). On Fri, Nov 23, 2018 at 5:34 PM David Aghassi <[email protected]> wrote: > Hello folks, > > I'm the initial author of > https://github.com/eslint/eslint/issues/10606#issue-341171187 > > As per the last post in that thread, it has been asked that an RFC be > drawn up for the idea. I'm posting here as it is suggested as per the > README of https://github.com/eslint/rfcs/. I'd like community input > before drawing up the RFC. > > Currently, ESLint is a completely synchronous process and (aside from > caching) doesn't offer must optimization for large codebases. In our > enterprise build tooling, ESLint is one of the main slow downs at build > time. It would be ideal to have a threaded/async way of handling static > analysis. I've not specifically had much experience in this area, but > wanted community input on how people think this should be implemented. The > way I see it based on the existing discussion is: > > * Continue to support CLIEngine in the current form > * Create a version of CLIEngine that is meant to only be for > Async/Threaded linting (thus allowing new users to opt into this system) > * Discuss/decide the optimal way to use workers/thread pools across > operating systems > * Discuss any draw backs of offering an async/threaded engine > * Discuss why this would or would not benefit the community > > I'll leave the discussion pretty open for this. I'd like to see this > through because I design tools for developers at scale and am always > looking for where we could provide performance gains for iterating on code. > > -- > You received this message because you are subscribed to the Google Groups > "ESLint" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- ______________________________ Nicholas C. Zakas @slicknet Author, Principles of Object-Oriented JavaScript <http://amzn.to/29Pmfrm> Author, Understanding ECMAScript 6 <http://amzn.to/29K1mIy> -- You received this message because you are subscribed to the Google Groups "ESLint" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
