There's an abundance of truly great tools to help improve your codebase, but it's tough to remember all of the right parameters and options for each. And even then, it's a lot of typing.
I'm working on something to help make it easier and more natural to put all of these great tools to work together in a way that scales even if you have a dozen tools to run against your codebase, and even if you run some tools in one context and other tools in another context.
They'll consistently apply their correct configurations and make it friction-less to keep your code in tip-top shape.
What if, instead of...
> yarn audit --level moderate
> bundle exec bundle-audit check --no-update
> bundle exec rubocop --parallel
> bundle exec erblint --lint-all --enable-all-linters
> yarn stylelint .
> yarn eslint .
...you could just type...
> rvw
And what if when it ran all of your desired tools, instead of flooding the screen with output when it's successful, it showed concise and readable output without any "noise" unless the tool fails.
And what if it also told you how long each tool takes to execute in case you only want to run the slow tools in specific contexts?
Bundler Audit · Review Gem Dependencies for Security Issues
Success (2.064s)
Minitest · Unit Tests
Success (1.339s)
Rubocop · Review Ruby Syntax & Formatting for Consistency
Success (2.841s)
But when the tool finds a problem, what if it knew not to run any subsequent tools and showed you just that failure? So instead of scrolling back through a ton of successful output, it only shows you the bits you need to fix so you can focus on that.
Inch · Review Ruby Documentation
$ bundle exec inch > /dev/null
Failure · Exit Status 10
Re-running Inch verbosely:
$ bundle exec inch
# Undocumented:
┃ U ↑ Reviewer#review
┃ U ↑ Reviewer#format
Then sometimes you may just want one tool, and you want it to run with the correct settings without remembering all the right flags:
> bundle exec rubocop --parallel
...becomes...
> rvw rubocop
But then other times you want to run multiple tools, but not all of them, so what if you could easily run subsets of those tools in different contexts?
> rvw security # Only run the tools that check for security issues
> rvw syntax # Only run the tools that review syntax
> rvw ruby # Only run the tools that review ruby code
> rvw ci # Only run the tools you need for Continuous Integration
> rvw pr # Only run the tools you want for a new Pull Request
> rvw fast # Only run the tools you've tagged as 'fast'
> rvw slow # Only run the tools you've tagged as 'slow' so you can easily run them less frequently
And sometimes it's handy to only review specific files or sets of files without having to remember each tool's unique syntax for specificying files:
> rvw app/models/user.rb
> rvw app/models/user.rb,app/models/organization.rb
> rvw app/**/*.rb
Or for those times you only want to review a file based on its state:
> rvw staged # Run all the relevant tools against your staged files
> rvw untracked # Run all the relevant tools against your untracked files
Or you may even want to mix and match capabilities:
> rvw staged ruby
> rvw rubocop staged
And since some of these tools can auto-correct in some cases, what if you didn't have to remember which tools could do that or remember whether the flag is --write, --fix, --auto-correct, or something else?
> fmt
...and what if the fmt command worked just like the rvw command...
> fmt staged
> fmt ruby
...and since running a handful of tools can frequently mean updates or tools that aren't installed, so what if it could also proactively direct you to installation instructions if a specified tool isn't installed...
> rvw
Missing · A tool that isn't installed.
$ bundle exec missing > /dev/null
Failure · Missing executable for 'Missing'
Installation Command:
bundle exec gem install missing
Installation Help:
https://example.com/missing/install
And all it takes is a little YAML to set up your desired tools. And chances are good most of the tools you want to use already have common YAML configurations already done for you.
And one more thing. Wouldn't it be nice if you could set up personal defaults that you could use across projects without having to install these tools into every codebase you touch? But, if you happen to be working on a codebase that already had them installed, it would use the codebase settings instead of your personal settings? Yeah, it's gonna do that too.
And that's just the beginning.
Sound nice? Stay in the loop: https://twitter.com/garrettdimon