While I can the frustration, I'm very disappointed by this. I have taken (and am taking) steps to make it easier for me to deploy new builds. I'm also looking into ways to automate the update process.

I would much prefer if you reach out to me and talk about the issue so that we can come up with a solution that benefits everyone.

Hi @fkling!

I'm more than happy to work with you on this.

If we can work out a solution that removes the need to manually PR for minor bumps, then that will be the vast majority of the pain points covered and closed.

Even better would be if we could somehow tie into NPM, so that we can use our canary versions (which are created for every master commit).

Some more background on this:

astexplorer.net has become a major part of my workflow for managing this project, and I know pretty much every contributor relies upon it as well for quickly inspecting the AST shape when writing rules.

I have a local copy of the repo, which I yarn link our master into, but even after cutting out everything I don't use (so everything except typescript, typescript-eslint, babel, and the eslint transformer), the build time is still pretty long.

I opened this issue after waiting ~5 min for a build, thinking that maybe I should just automate the process so I don't need to burn time waiting for a build. I thought doing so would have the added benefit that all the contributors can have the latest version ready to go for every canary release, without going through the same process.

I figured it would have been pretty trivial to push my trimmed fork, and configure a daily (or even hourly) azure task to publish the build. It seemed like a good stop gap until a more scalable maintenance plan was sorted for the astexplorer repo.

At the time as well, there was an indeterminate lead-time for PRs getting merged, which doesn't sync well with our weekly release cadence.

Finally, I was thinking about adding in tooling to add type information to the output, to try and make it easier for contributors to create type-aware eslint rules.

Since then, someone has released https://ts-ast-viewer.com/, so I don't have a need for the latter tooling for showing type information, and the versions in your repo have been bumped to be much closer to what we need (TS 3.7, and @ts-eslint v2+).

I never closed this because I had forgotten I opened it.