Problem

JavaScript dialects like Flow and TypeScript often have additional utilities that can be used for various purposes (i.e., a type checker). Currently, there is no way to easily expose these utilities to rules, as they sometimes require access to the state information that created the AST (the TypeScript type checker is like this). This cuts off ESLint rules from useful utilities.

Background Discussions

eslint/typescript-eslint-parser#61 (comment)
#5040 (comment)

Proposal

tl;dr Allow parsers to optionally export parser services that can be retrieved through a new method on the context object.

First, allow parsers to expose a special parseForESLint() method in addition to the de facto standard parse() method. The parseForESLint() method would receive the same argument as parse(), but would return an object in this form:

{
    ast: ast,     // the AST as returned from parse()
    services: {
        serviceName: someObject     // a service to provide to rules
    }
}

If parseForESLint() is found, that will be used by ESLint, otherwise parse() is used. Doing this allows us to add additional ESLint-specific properties without needing to add them on an ESTree structure (where they don't belong). This also opens up the possibility of adding other ESLint-specific functionality in this return object in the future.

Then, we'd add a context.getParserService() method context.parserServices object such that you can use it in a rule like this:

var service = context.parserServices.serviceName;

There would be no restrictions on the type or format of services that can be exposed through this mechanism. It's completely free-form.

I'd love to get some feedback on this proposal from @JamesHenry @jeffmo @hzoo @alexeagle