Replacing Shell Scripts with Cross-Platform TypeScript

Hi, everyone. I'm David Sherrit, a developer at Deno, and today I'm going to talk about why you should replace your shell scripts with cross platform TypeScript. This is not a talk just for JavaScript developers, but for developers from any language and background. Personally, TypeScript is not my primary language, but I use it in almost all my projects, and this talk will outline how and why you should also consider doing that.

So why do we use shell scripts? We often use them because they work out of the box on the system we're on, so that's convenient. They are easy to spawn. They have concise syntax, and they execute similarly to what we write on the command line. So if you have a command you often run in your terminal, you can often just copy and paste it into your shell script. There's some downsides, though. The first major downside is it's system dependent. Shell scripts can't be taken and run on every platform. Mostly, they won't run out of the box on Windows. Sometimes this is even the case across Unix-based systems, depending on how the shell script is written. Also, basic Unix commands don't work on Windows out of the box. And telling Windows developers to use WSL is not a great solution. That can require them having to set up a new development environment within WSL just to run the script. Shell scripts are great if you're executing a few commands. But it's difficult to increase functionality without drastically increasing complexity. Another point specifically for JavaScript developers, is shell scripts present code we need to maintain in yet another language. We also can't pull in and use our favorite JavaScript libraries. Finally, there's no type checking. We don't get code completion to help us develop, and all the other nice tooling that TypeScript provides.

Now, why should you use TypeScript instead of shell scripts? First of all, it's familiar, and TypeScript and JavaScript are popular languages with a large community. Many developers have at least touched JavaScript or could at least understand its syntax. Second is type checking and tooling. A very large benefit of TypeScript is that its tooling is great, even if we're just using JavaScript. We get features like code completion, go to definition, and type checking errors in the editor. Now, this talk is not just about why you should replace shell scripts with TypeScript, but also why you should use Deno while doing that. First of all, it's far easier to write cross-platform scripts in Deno than shell scripts, because most APIs work cross-platform. Obviously, there's some platform-specific APIs, if you need them, but usually we don't have to reach for those.

Second is single file scripts. I'm obviously biased, but I think Deno is the best platform for writing single file scripts. For example, in Node, using TypeScript requires extra setup. You need to have a package.json file to define dependencies. This also requires anyone running your scripts to have to remember to run npm install first and also after any changes to the dependencies. That process then creates a Node modules folder in the directory tree. So right there you have two extra file system entries, so it's not a single file script.

Whereas in Deno, TypeScript is supported out of the box, so you can execute TypeScript code directly. It's optional to use a config file to define your dependencies, and it's also optional to have a Node modules folder for vendoring npm dependencies. It's important to note that you can still use that model if you want, but it's opt-in. Third, dependencies are auto-installed based on the code, so no separate npm install setup command is necessary. Finally, Deno is sandboxed by default. Node recently got an experimental permission system, but it's opt-in rather than opt-out.

Another great thing about Deno for single file scripting is it's possible to define the dependencies in the script file itself. For example, you can pull in packages from npm or use https imports to easily host scripts on a web server and reference those directly. One bad part about this is it's verbose to launch sub-processes using a low-level process API available in both Node and Deno. But that's not a big deal because we can pull in a dependency that helps make it more like shell scripts.

There's a library I wrote called dax. Dax is a cross-platform shell written in JavaScript that has common cross-platform Unix commands built right in. It also has other useful APIs to help out with scripting. Here's some examples of running commands. The shell syntax it supports is a common syntax found in shell scripts. For anything more complex, like loops, you probably just want to use JavaScript for that instead. Again, to emphasize, all the code shown here works on Windows. Launching commands is slightly more verbose than shell scripts for simple cases, but in my opinion, the advantages of being able to write these scripts mostly in JavaScript outweighs the slight extra verbosity when launching commands. Also, it could be argued that this is less verbose in complex cases. For example, as shown on the last line of this code, accessing properties on the JSON output of a command is quite easy.

Finally, DAX has logging APIs, a path API. For example, here we create a path ref object for the source directory, get if it's a directory, then call mkdir on it to create the directory. Then we get a reference to a text file within that directory, write some text to it, or we could even read from that text file. Or we could write some object as JSON to a file, or read from it deserializing to a JSON value. There's also APIs for doing prompts, making selections, and showing progress. Finally, there's a request API built in that's similar to the fetch API, but less error-prone, and with some additional helpers on it. Anyway, there's a lot more to this, and I'd recommend checking out the documentation for more details.