search

noseglid / atom-build

:hammer: Build your project directly from the Atom editor
https://atom.io/packages/build
MIT License
248 stars 97 forks source link

Upgrade to linter-indie 2.0 format for atom-ide-ui #535

Open dnsco opened 6 years ago

dnsco commented 6 years ago

Build errors don't show up in the atom-ide-ui/nuclide diagnostics ui because atom-ide-ui-diagnostics only consumes linter-indie 2.0 and we provide 1.0 (their diagnostics replaces the linter package)

ide-diagnostics package.json vs atom-build package.json

I can look in to upgrading to the indie-linter v2 api, but wanted to make sure you didn't have an offhand reason for why it would break everything. I could also be misunderstanding how all of this works. Linter Upgrade Doc

noseglid commented 6 years ago

I don't see any reason why we shouldn't upgrade. I'd love a PR for that

doudou commented 6 years ago

I'm getting interested in this as well - I can provide some manpower. @denniscollective do you have any WIP in this direction already ?

@noseglid as far as I can see, atom-build's match structure is basically passed as-is to the linter. If that's true, then I see three possible paths:

  1. require the functionMatch implementations to follow, by bumping the build service version itself
  2. "convert" linter 1.0 messages to linter 2.0 messages internally
  3. make build provide both linter v1 and v2 service versions, and dispatch the matches accordingly internally (not bumping the build service version itself). The backward-compatible change would be that build services should tell if they generate linter v2 messages (i.e. adding a linterVersion() method on the build service providers, and default to linter v1 if the function does not exist).

I would go for (3) personally. Thoughts ?

dnsco commented 6 years ago

@doudou I took a crack at it but failed to produce anything of value, I'm stoked to pass the reigns!