Promote Lint out of internal + Backwards compatibility checker

[jhaals]

Hi!

I very much like the work you're doing with prototool.
We are in the process of improving the workflow for consuming and managing protos and originally started building on https://github.com/spotify/protoman but we paused that work for now when we realized the project was expanding to a full fledged package manager. There's also the fact that other companies are facing the same questions as us and we're hoping for some consensus on the best general approach instead of building something in isolation.

We recently took a few steps back and made a simpler/short term approach modeled around having a monorepo with all IDLs. Then constructed a simplified protoman in Go for fetching the latest version and it's dependencies using the Github API. We where hoping to include your linter so that we don't have to run multiple tools for linting/fetching IDLs but were unable to do so due to the internal package path. Would you be open to having your linter not be internal to prototool so that it can be used by other tools?

We're also planning porting our check for backwards incompatible changes from Java to Go, would you then be interested in having it contributed to prototool?

[blampe]

Thanks for reaching out, glad you're finding this useful.

This sounds like a super reasonable request. The reason we bundled most of this stuff under internal was to avoid prematurely committing to a bunch of public APIs. We'd need to give a little thought to how we expose this but it should be doable. We're very open to any API suggestions you have.

We recently took a few steps back and made a simpler/short term approach modeled around having a monorepo with all IDLs. Then constructed a simplified protoman in Go for fetching the latest version and it's dependencies using the Github API.

Sounds very similar to the direction we're taking as well, so that's a good sign :)

We're also planning porting our check for backwards incompatible changes from Java to Go, would you then be interested in having it contributed to prototool?

This would be amazing! We were planning on tacking this next and we would welcome any help!

[jhaals]

I understand the reasoning behind internal. I think most would be okay with some evolution underlying packages given that the prototool CLI is the main consumer. I'm not familiar with the lint package yet but we should be fine as long as we can do a mix of both package provided and custom checks, looks like that should be possible already except for the package path.

I'm glad to hear that we're heading in the same direction! That's usually a good sign :) We should perhaps try to tackle these things together instead of doing it in isolation.
We're doing the same directory structure like https://github.com/googleapis/googleapis
Consumers would then $ cli get foo/bar -o dst which would download all protos from foo/bar to dst/foo/bar and their dependencies to the corresponding folders. Are you already doing something similar or planning to?

[peats-bond]

Yes! We have a similar tool internally that we've developed, reminiscent of uber-node/idl (which might get an external revamp).

Also, I've sent you an email to the address listed on your Github account!

[jhaals]

Fantastic! Yes let's not derail this issue any further :)

[peats-bond]

Closing this as our discussions have moved off of github