
Open Sourcing Oclif, the CLI Framework That Powers Our CLIs - craigkerstiens
https://blog.heroku.com/open-cli-framework
======
jetblackio
Congratulations on open sourcing this. It looks great. Is there a reason you
went with Node.js instead of something like Go? As a sysadmin, I personally
hate having to deal with dependencies from tools built in non-compiled
languages like Python, Node and Ruby.

~~~
dickeytk
We did try to partially write it in Go. Writing it fully in Go would not have
be possible because of the plugin system we have. However we struggled with Go
quite a bit and ultimately dropped it from the codebase. This article gets
more into detail as to why: [https://blog.heroku.com/evolution-of-heroku-
cli-2008-2017](https://blog.heroku.com/evolution-of-heroku-cli-2008-2017)

~~~
dickeytk
We also have some tools we use with the Heroku CLI we will be backporting into
oclif very soon that directly addresses this problem node has with
distribution. Essentially it's some scripts that let you export an oclif CLI
as a standalone tarball (node binary into it), optionally being able to
autoupdate with github or s3.

oclif is also compatible with pkg
([https://github.com/zeit/pkg](https://github.com/zeit/pkg)) which will turn
the CLI into a dependency-less single binary just like it would be with Go. I
don't like it personally as I find it useful for debugging to actually edit
the files. With Go we would have to cut a release just to add extra debugging
information.

------
drew-y
Neat! I've got a similar library, Cliffy[1], also written in Typescript. But
it's designed to be run interactively in-proccess.

[https://github.com/drew-y/cliffy](https://github.com/drew-y/cliffy)

~~~
dickeytk
very cool! Doing it in process definitely allows for some cool things.
Specifically this: [https://cloudplatform.googleblog.com/2018/03/introducing-
GCP...](https://cloudplatform.googleblog.com/2018/03/introducing-GCPs-new-
interactive-CLI.html)

------
nickjj
What makes this better for building CLIs than using something like Thor with
Ruby or Click with Python?

I mean, from the 1 minute video that's posted on the page, it just looks like
it's a basic Node library to help tackle some common CLI requirements and it
happens to have generators.

~~~
dickeytk
The major advantage oclif has is plugins. Plugins are a way to share code
between CLIs or organize within a CLI. At Heroku, different teams manage their
own CLI plugin and each of those plugins have their own set of dependencies.
These dependencies will not conflict with each other. It's a great way to
share code and modularize a large CLI's codebase.

This kind of setup isn't possible with Ruby (to have multiple dependencies of
different versions). I'm not sure if it's possible with Python, but I don't
think so. Node's dependency model naturally supports this behavior though.

I haven't used thor in years and only looked at the docs for click. For a
large CLI built in a scripting language, lazy loading of commands is crucial.
It appears that click supports this, but my cursory reading of the thor docs
looks like that one does not have lazy loading.

I have a lot of experience trying to deliver the Heroku CLI as a ruby CLI and
I can tell you first hand that dealing with ruby as a runtime dependency vs
node is a world of difference. Node is simply far easier. Also, we will be
coming out with a plugin for oclif within the next few months that will help
you build dependency-less tarballs so the end-user doesn't need to even have
node installed. (You can also do this today with oclif just by using pkg) This
is also going to come with a couple options for adding autoupdates that won't
depend on the local npm. The goal is to make distributing CLIs as easy as
possible and have it not conflict with anything that may or may not be on the
end-user's machine.

If you're just building a small CLI, I don't think between these tools you'll
notice much of a difference. Just use the one in the language you feel more
comfortable in. oclif is really meant to solve a lot of the problems we've had
with large CLIs (sharing code, distribution, dependency management,
versioning, namespacing) and abstract away common issues end-users have with
setting up.

The choice of node is also helpful for large codebases like what we have at
Salesforce and Heroku. This is an area where people's main job is writing in
many different languages but everyone knows at least _some_ javascript. This
means that even if javascript isn't their favorite language, they're still
able to jump in and write code. Often CLI code just isn't that complicated
either (usually doesn't involve any memory management as the application is
only running for less than a second, for example), so the language choice I
feel doesn't matter as much as it would compared to back-end development.

~~~
nickjj
Thanks for the response, fair enough.

------
jvoorhis
The name appears to be Japanese keyboard vendor FILCO, spelled backwards.

~~~
aaronbrethorst
I’m pretty sure it’s an acronym for Open CLI Framework.

