Bundle linter in the core

[steelbrain]

Atom is a Code Editor/IDE for Developers and those developers make mistakes. A base linter provider is something that everyone needs. There was a time when linter API and codebase wasn't shiny enough for it to be made a part of core.

But now we have rebuilt the linter package from the ground and consumed the latest technologies (i.e services) to provide API to linters. It's API and other docs can be found in the linter-plus wiki. It's API is inspired from the awesome autocomplete-plus. The rewrite also features a completely new UI based on suggestions from the AtomLinter Org members and styles from @simurai . Furthermore it accepts anonymous objects as messages allowing the providers to write unit-tests.

It also has a UI to show errors from the current file or project. Which is very important for the Nuclide IDE and project-based languages like FlowJS, HackLang and others. and the Error Objects can contain traces that expand over the lines. It is also extremely easy to style. and It doesn't have to save a temp file to disk to lint files. It also supports lintOnFly and onSave linters.

It even exports it's self service to packages who have daemons in separate processes and want to trigger lint without waiting for a save or change in the buffer. Also in the tooltip and bottom panel are positions that user can click on and be directed to the file:line:col instead of just jumping to the next error.

All these features remove all of the known limitations of old linter package.
Note: It's also backward compatible, so all the linters using the old API will still work.

Here is how it looks like at the moment

There are a lot of packages that have re-invented the wheel and written their own error UIs. If we merge linter in the core, all those packages can consume a similar API and eventually reduce their code complexity.

Things to be done

• Make the code shine bright (We have been working hard on this one)
• Move it to the atom org.

Let us know what you guys think.

[50Wliu]

/cc @atom/feedback

[basarat]

💯 Every other package needs this feature. Almost as much as autocomplete-plus was needed.

[keplersj]

So I was the person who initially thought this would be a good idea while the new API was being created.

To see a good part of the story behind this proposal please see these issues:

• AtomLinterPlus/linter-plus#1
• AtomLinter/linter-plus#47

About two weeks ago we had an internal power struggle at AtomLinter, it was not pretty. I was on my way home and my phone had blown up with notifications coming from GitHub and Gitter. Reading over the notifications and all the weight they carried an idea occurred to me, we're all trying to ensure the best for this project because we all believe it essential to the Atom coding experience. Soon I began to realize something. Knowing where issues exist in your code is essential to coding, therefore it should be an essential part of an editor. Embedding the core linting package in the editor allows us to better serve a wider community of people trying to accomplish the same essential goal, knowing where issues in your code exist.

Looking at the past two issues this conversation were contained in, you will be able to see that there are a decent number of people in support of this integration; people who would be better served by a central way to display errors in the editor.

[anaisbetts]

Being able to detect and display errors in code seems like it is an excellent candidate for inclusion as a part of the core product of Atom, especially given:

1. This project will be used by nearly everyone using Atom (at least the people Doing It Right)
2. Linting has the potential to have a significant impact in terms of performance and user experience (both negatively and positively)
3. Linting has an ecosystem which would significantly benefit from a stable, well-designed and documented API

To be super clear, I'm not at all saying that the current project is failing in these last two regards! Only that these two items are particularly important to Atom as a product. So in summary, 👍 to including this in the core Atom repo

[lierdakil]

👍 Various IDE packages could benefit from this a lot.

[Zireael07]

Great to see linting being considered for core - I know some people had lags with the current linting packages.

[ghost]

👍 excellent idea

[joefitzgerald]

👍 /cc @benogle we should discuss this on Thursday 😄.

[mnquintana]

Related: https://discuss.atom.io/t/canonical-linter-for-atom/14091

[steelbrain]

@mnquintana btw, this new linter is fast as hell 😃

[lee-dohm]

I feel we should settle the issue of a view API before anything like this is considered. If this is a necessary component, which I agree with @paulcbetts that it is for anyone Doing It Right™, then that means to me that its underpinnings are necessary too. One of the main things this is intended to provide, to my understanding, is UI for linters and related tools. Shouldn't we standardize the basic UI API first?

There are other things that I feel are higher priority than merging anything into core:

• Releasing v1.0
• Font measurement, CJK and other high Unicode support
• Better international support, including keyboards

I feel we should be fixing the things that we all agree are broken before we go about adding to the Core Team's support burden.

[joefitzgerald]

@lee-dohm Please beware of making this (linter in core) seem like a mutually exclusive thing when comparing it to the items you mentioned (1.0 / unicode / internationalization, etc.) - or something that can only be done serially, after those you mentioned.

By way of example: this discussion about autocomplete-plus making it into core started about 5-6 months prior to it being included. Getting a rough 👍 from the core team that this (even if not currently the priority) will become a priority is critically important to those doing the work, and it also generally causes that team to seek input from the core team for key design decisions. These are good things in my opinion.

This discussion should happen now, with the knowledge that actual inclusion in core requires a core team member to "internalize" the package(s) to be included in core and potentially modify some portions of them such that they can be supported on an ongoing basis.

A core linter package might not be the top priority right now, but I think the linter team is looking for a guarded 👍 (or an outright 👎) from the core team, with no strings attached for the actual schedule for core inclusion.

[joefitzgerald]

One of the main things this is intended to provide, to my understanding, is UI for linters and related tools. Shouldn't we standardize the basic UI API first?

Actually, the most important part of linter is not the UI - it's the API it provides, and its ability to dispatch lint requests (on save, on keystroke, on file open, etc.) and collect results (info / warning / error messages). This ensures that whenever a UI API is finalized, a change is required in only one place instead of n places. I don't see the UI portion of this to be a blocking factor.

[keplersj]

@joefitzgerald In fact our current API isn't even limited to info, warning, and error messages anymore. You can pass any message of any type to it and it will display/react accordingly. One could use the current API and pass a Result message from a build system, for example.

[mnquintana]

In fact our current API isn't even limited to info, warning, and error messages anymore. You can pass any message of any type to it and it will display/react accordingly. One could use the current API and pass a Result message from a build system, for example.

That's pretty cool, but it makes me think that linter-plus might be due for a name change at some point, since its use cases are expanding beyond just linting.

[keplersj]

@mnquintana Any suggestions for a new name? Could be something to do if we do get inclusion in the core.

[joefitzgerald]

[...] it makes me think that linter-plus might be due for a name change at some point, since its use cases are expanding beyond just linting.

Agreed. In the abstract, the packages takes events (save, keystroke, file), matches them with registered things to run, runs things, collects results, and optionally displays the results.

[thedaniel]

We'll talk about this in our weekly meeting tomorrow. The whole team will be traveling to a conference and/or working on 1.0 next week so we probably won't go in depth on it but hopefully we'll at least come up with a response for this thread.

Also, we plan to work out the ~6month roadmap in mid July. It's good to talk out the details now but by then we should be able to say something decisive in the range from "yes, and the core team will work with you on it" to "we think it belongs in a package" to "keep doing what you're doing and we'll revisit it with you in a few months after XYZ"

[thedaniel]

OK, short answer is this: we're interested in bundling a linter service in core. 🎉✨👍💯

Linter-plus seems like a great place to start.

We're most comfortable with a process that looks like the following: at some point in the future someone from the core team will work closely with the linter-plus developers for a few days to work out what might need to be changed, improved, or cut for us to feel comfortable supporting it in core - we'll work out a spec together and then the linter-plus team can polish up the code, and when we agree it's ready we can ship a new major version and put it in core. (This is similar to the process @joefitzgerald et al. went through with @benogle on autocomplete-plus, though likely less hands-on as the linter API surface / codebase is pretty small.)

If you have plans in place to make linter-plus better today, by all means keep on doing what you're doing. We'll revisit this in more detail down the road. I encourage you to keep the scope of the linter service reasonable and resist adding lots of features, because I think we'll be focused on keeping the service simple for consumers, focused on the traditional lint use case, and having UI components with really well-polished design.

[keplersj]

Awesome! Thank you for the great news!

[iam4x]

Thank's guys, looking forward to have your advices. 👏

[Stanzilla]

Is this actually happening now?

[AsaAyers]

@steelbrain took sole ownership of the linter, so I'm thinking it seems unlikely. He's in the middle of extracting the whole UI into a separate package.

https://github.com/atom-community/Linter is now https://github.com/steelbrain/linter

[steelbrain]

I want to make it clear to everyone that the repo has only moved location and nothing else. I still plan on bundling this in core eventually.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[keplersj]

@damieng?

[lee-dohm]

With the release of the Atom IDE set of packages, we've added the desired functionality to Atom core. In addition, the Atom IDE system supports the language server protocol with a standard UI for a number of additional features. Check out the Atom IDE minisite to get started.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!