Proposal: IDE integration API

[fson]

After thinking about current problems with configuring editor integrations with zero configuration projects I came up with this approach: provide a single API for IDE plugins to integrate with all the underlying tools.

Problem

@gaearon described the problem well in #215. For example, IDE integration with ESLint currently requires the eslintConfig setting in package.json and manually installing ESLint globally with all the correct plugins. This goes against the zero configuration philosophy of this project and having the setting in package.json also gives an illusion that the ESLint configuration can be changed, which is not true.

It also requires the user to know which tools react-scripts uses internally and to configure integrations for each of them separately. Ideally the fact that react-scripts uses ESLint and particular ESLint plugins for linting should be an implementation detail.

Solution?

Create React App would provide a programmatic API for IDE integrations. The API would allow IDE plugins to surface various errors and warnings in the editor UI:

• Compiler errors (Babel/Webpack)
• Linting errors (ESLint)
• Type errors (Flow)
• Test failures (Jest)

Having a single API for these would remove the need to install and configure multiple IDE plugins: the user would simply install a Create React App IDE plugin and get the integrations with all the underlying tools at once. And if some day we wanted to change react-scripts to use a different compiler or linter, as long as the IDE API stayed compatible, the IDE plugins would keep working.

How would such an API look like? The details are open, but at the moment I can imagine two possible main directions:

1. Build the API into the development server. It would work similarly to webpack-dev-server. It could be similar in principle to webpack HMR API: the IDE plugin would connect to the server via WebSocket or other streaming interface and the server would report any errors/warnings to the IDE in real time.
2. Add a task to package.json scripts that would run all the checks and return the output in machine readable format (JSON). The IDE plugin would look for the task in package.json and run it if found. (This would be similar to @vjeux's proposal in #215, but with the difference that instead of a single tool such as ESLint, the task would run all the checks implemented in CRA.)

(2) would be possibly easier to implement than (1), but might not provide as good developer experience as (1), since spawning a new process each time a file is saved could make the feedback loop slower.

I think a good first step towards a unified IDE API like this would be to implement a plugin for a single editor (e.g. Atom/Nuclide) that would provide high quality integration with CRA apps. If this approach proves useful in practice, it could be adopted in other IDEs and possibly other zero-config projects in the future too.

What do you think? Can we build this to get a great IDE integration with all the tools out-of-the-box?

[timdorr]

For my Ruby code, I use RSpec and code in RubyMine. One thing that's really awesome is RubyMine's integration into the RSpec runner. I have some keyboard shortcuts where I can jump from a controller or model file over to its accompanying spec file, and then based on my cursor position in that spec file, I can run the individual test (or group of tests) I have selected. It looks like this:

It does this by hooking in a special formatter to RSpec, which essentially lets it communicate with the IDE directly.

I wonder if that might be a better API. Rather than trying to hook into the tools, encourage them to provide the hooks themselves. That would go beyond supporting just CRA to basically enable support if you've ejected or never used CRA at all. Then, CRA would be able to proxy through those integrations to the underlying toolchain, but via intentional APIs instead of just hacking their way in.

This is obvious a much bigger proposal than what you originally intended, but I think would make the most sense for the ecosystem and community at large.

[gaearon]

I feel like this is too ambitious. It would be a cool separate project but I don’t think CRA is at the point where it can unify all these tools in a meaningful way. It is not clear how this would work post ejecting.