Shell scripts serve a useful purpose, but they have some downsides. What if we could overcome these issues and make our scripts more powerful by utilizing familiar cross-platform TypeScript? In this talk, we'll discuss why you should switch your shell scripts to TypeScript and demonstrate a possible approach.
Replacing Shell Scripts with Cross-Platform TypeScript
AI Generated Video Summary
The speaker discusses the benefits of replacing shell scripts with TypeScript, highlighting the limitations of shell scripts and the advantages of TypeScript such as cross-platform compatibility and better tooling. Deno is presented as the ideal platform for single file scripting, with its built-in support for TypeScript, automatic dependency installation, and sandboxing. The dax library is mentioned as a useful tool for scripting, providing a cross-platform shell and other APIs. Overall, the Talk emphasizes the power and flexibility of using TypeScript and Deno for scripting purposes.
1. Why Replace Shell Scripts with TypeScript
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. 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. We often use shell scripts because they work out of the box on the system we're on, but there are downsides. Shell scripts are system dependent, can't be run on every platform, and don't work on Windows out of the box. TypeScript, on the other hand, is familiar, has great tooling, and allows for cross-platform scripting in Deno.
2. Advantages of Deno for Single File Scripting
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.
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.