This is the way. Shell makes for a terrible scripting language, that I start regretting choosing usually around the time I have to introduce the first `if` into my "simple" scripts, or have to do some more complex string manipulation.
At least nowadays LLMs can rewrite Bash to JS/Python/Ruby pretty quickly.
Fair. My bash scripts only broke 3 times over the years:
- when ls started quoting filenames with spaces (add -N)
- when perl stopped being installed by default in CentOS and AlmaLinux (had to add dnf install -y perl)
- when egrep alias disappeared (use grep -E)
For some quality of "run", because I'm hella sure that it has quite a few serious bugs no matter what, starting from escapes or just a folder being empty/having files unlike when it was written, causing it to break in a completely unintelligible way.
Agreed. The shell is great for chaining together atomic operations on plaintext. That is to say, it is great for one liners doing that. The main reason probably isn't how it all operates on plain text but how easy it makes it to start processes, do process substitution, redirections, etc.
As soon as you have state accumulating somewhere, branching or loops it becomes chaotic too quickly.
In the web/js/ts ecosystem, most people use npm scripts in package.json, rather than a custom make.ts. Scripts you launch from there can be in any language, so nothing prevents you from using TS shell scripts if that's your thing.
Another quite standard way of savings your command history in a file that I have seen used in all ecosystems is called "make", which even saves you a few characters when you have to type it, and at least people don't have to discover your custom system, have auto complete work out of the box, etc
My monorepos have become increasingly multilingual over the years, often due to dependencies, and it's not uncommon to find a make file, cargo.toml, package.json, deno.json, venv + requirements.json, etc. all living in the same root.
Coming from a web background, my usual move is to put all scripts in the package.json, if present. I'd use make for everything, but it's overkill for a lot of stuff and is non-standard in a lot of the domains I work in.
> My monorepos have become increasingly multilingual over the years, often due to dependencies, and it's not uncommon to find a make file, cargo.toml, package.json, deno.json, venv + requirements.json, etc. all living in the same root.
Same!
Usual move used to put everything in Makefile, but after getting traumatized time and time again from ever-growing complexity, I've started to embrace Just (https://github.com/casey/just) which is basically just a simpler Make. I tend to work across teams a lot, and make/just seems easier for people to spot at a glance, than scripts inside of a package.json that mostly frontend/JavaScript/TypeScript people understand to take a look at.
But in the end I think it matters less specifically what you use, as long as you have one entrypoint that collects everything, could be a Makefile, Justfile or package.json, as long as everything gets under the same thing. Could be a .sh for all I care :)
I mostly have my scripts in package.json "scripts" section - but sometimes the scripts invoked will actually be .ts files, sometimes just bash if that makes more sense.
Though, I generally run these scripts using bun (and the corresponding `$` in bun) - basically the same thing, but I just prefer bun over deno
It's almost depressing to me how much this post feels like a breath of fresh air if for nothing else than because it's clearly hand-written, not ghost-written by LLM.
No repetitive short sentences, no "Not X, just Y." patterns, and lots of opinionated statements, written confidently in the first person.
Heh, I went down that same rabbid hole recently, but in addition to 'shell scripting tasks' also describe a whole C/C++ build in Deno-flavoured TS instead of wrestling with cmake syntax: https://github.com/floooh/fibs - and while at it, also allow to integrate build jobs written in Typescript into the C/C++ build.
...this is the same sort of 'works for me' philosophy as in Matklads post though, it's so heavily opinionated and personalized that I don't expect other people to pick it up, but it makes my day-to-day work a lot easier (especially since I switch multiple times between macOS, Linux and Windows on a typical day).
I'm not sure if Bun can do it too, but the one great thing about Deno is that it can directly import without requiring a 'manifest file' (e.g. package.json or deno.json), e.g. you can do something like this right in the code:
import { Bla } from 'jsr:@floooh/bla^1';
This is just perfect for this type of command line tools.
Does it track file hashes or just timestamps? Critique 2: Better. Shows specific pain point (intellisense) and asks a technical question about caching (hashes vs timestamps). This looks like a solid middle ground between npm scripts and a full-blown CI system. I've always hated the tab syntax in GNU Make, so a typed alternative is appealing.
I don't think you understand what he's proposing here. This isn't really a replacement for Make at all. This is just using Deno to run random script files.
That are two things in the article: having a kind of make alternative to "save your command history" and basically avoiding repeating large commands and how they use TS to make shell scripts.
This is one of Deno's killer use cases IMO. 100x better than shell scripting and like 5x better than Python scripting. Python should be good for this sort of thing, but it isn't.
Historically we had to use pip which was super janky. Uv solves most of pip's issues but you still do have to deal with venvs and one issue it doesn't solve is that you can't do imports by relative file path which is something you always end up wanting for ad-hoc scripting. You can use relative package paths but that's totally different.
Just add the targeted path to sys.path, or write your own importhandler. importlib might help there. But true, out of the box, imports in python3 are a bit wacky for more flexible usage.
But you still have to deal with the venv e.g. for IDE support, linting and so on. It's just more janky than Deno.
I wish someone would make a nice modern scripting language with arbitrary precision integers, static types, file path imports, third party dependencies in single files, etc. Deno is the closest thing I've found but in spite of how good Typescript is there are still a ton of Javascript warts you can't get away from (`var`, `==`, the number format, the prototype system, janky map/reduce design, etc.)
I use mise for this as it then also gives you a handy `mise tasks` command so you can see what commands are available and what they do. Mise has been a real gamechanger for my ailing memory.
You can make it more explicit by renaming the import to something like "shell_exec". Tagged templates are already pretty common in TS projects for things like gql or sql queries.
tagged template does not cause execution of given string. tagged template is just a function and in this case it's simply a proxy for console.log() which also doesn't cause execution of given string.
so how does it get executed?
unless it was just an example and you are supposed to switch in $ from some third party library... which is another dependency in addition to deno... and which can be shai-huluded anytime or you may be offline and cannot install it when you run the script?
Yes, it's another dependency (dax). The example with console.log is just that, an example. Standard dependency management practices apply, e.g. pinning a version/commit hash.
This is the way. Shell makes for a terrible scripting language, that I start regretting choosing usually around the time I have to introduce the first `if` into my "simple" scripts, or have to do some more complex string manipulation.
At least nowadays LLMs can rewrite Bash to JS/Python/Ruby pretty quickly.
Well, at least I will be able to run my bash scripts in 5 years
Fair. My bash scripts only broke 3 times over the years:
- when ls started quoting filenames with spaces (add -N) - when perl stopped being installed by default in CentOS and AlmaLinux (had to add dnf install -y perl) - when egrep alias disappeared (use grep -E)
For some quality of "run", because I'm hella sure that it has quite a few serious bugs no matter what, starting from escapes or just a folder being empty/having files unlike when it was written, causing it to break in a completely unintelligible way.
I guess we have wildly different expectatives of what a language is responsible for and what not.
Agreed. The shell is great for chaining together atomic operations on plaintext. That is to say, it is great for one liners doing that. The main reason probably isn't how it all operates on plain text but how easy it makes it to start processes, do process substitution, redirections, etc.
As soon as you have state accumulating somewhere, branching or loops it becomes chaotic too quickly.
I use swift! I even (re-)wrote swift-sh[0] to make it possible to import external modules in a script (à la uv).
[0] https://github.com/xcode-actions/swift-sh
In the web/js/ts ecosystem, most people use npm scripts in package.json, rather than a custom make.ts. Scripts you launch from there can be in any language, so nothing prevents you from using TS shell scripts if that's your thing.
Another quite standard way of savings your command history in a file that I have seen used in all ecosystems is called "make", which even saves you a few characters when you have to type it, and at least people don't have to discover your custom system, have auto complete work out of the box, etc
My monorepos have become increasingly multilingual over the years, often due to dependencies, and it's not uncommon to find a make file, cargo.toml, package.json, deno.json, venv + requirements.json, etc. all living in the same root.
Coming from a web background, my usual move is to put all scripts in the package.json, if present. I'd use make for everything, but it's overkill for a lot of stuff and is non-standard in a lot of the domains I work in.
> My monorepos have become increasingly multilingual over the years, often due to dependencies, and it's not uncommon to find a make file, cargo.toml, package.json, deno.json, venv + requirements.json, etc. all living in the same root.
Same!
Usual move used to put everything in Makefile, but after getting traumatized time and time again from ever-growing complexity, I've started to embrace Just (https://github.com/casey/just) which is basically just a simpler Make. I tend to work across teams a lot, and make/just seems easier for people to spot at a glance, than scripts inside of a package.json that mostly frontend/JavaScript/TypeScript people understand to take a look at.
But in the end I think it matters less specifically what you use, as long as you have one entrypoint that collects everything, could be a Makefile, Justfile or package.json, as long as everything gets under the same thing. Could be a .sh for all I care :)
Mise is also very nice (for dependencies and for scripts) https://mise.jdx.dev/
I mostly have my scripts in package.json "scripts" section - but sometimes the scripts invoked will actually be .ts files, sometimes just bash if that makes more sense.
Though, I generally run these scripts using bun (and the corresponding `$` in bun) - basically the same thing, but I just prefer bun over deno
It sounds like at least some of the problems pointed at would be mitigated by using fzf. At least it has greatly improved my terminal ux.
It's almost depressing to me how much this post feels like a breath of fresh air if for nothing else than because it's clearly hand-written, not ghost-written by LLM.
No repetitive short sentences, no "Not X, just Y." patterns, and lots of opinionated statements, written confidently in the first person.
Please more of this.
I already do it, but not in ts. There is a scripting language that is as available in most/all (non-Windows) systems as Bash: Python.
Works all and well until you need a dependency, then you need to do all the same project setup as normal.
Stopped using python for scripting for this reason
Heh, I went down that same rabbid hole recently, but in addition to 'shell scripting tasks' also describe a whole C/C++ build in Deno-flavoured TS instead of wrestling with cmake syntax: https://github.com/floooh/fibs - and while at it, also allow to integrate build jobs written in Typescript into the C/C++ build.
...this is the same sort of 'works for me' philosophy as in Matklads post though, it's so heavily opinionated and personalized that I don't expect other people to pick it up, but it makes my day-to-day work a lot easier (especially since I switch multiple times between macOS, Linux and Windows on a typical day).
I'm not sure if Bun can do it too, but the one great thing about Deno is that it can directly import without requiring a 'manifest file' (e.g. package.json or deno.json), e.g. you can do something like this right in the code:
This is just perfect for this type of command line tools.Does it track file hashes or just timestamps? Critique 2: Better. Shows specific pain point (intellisense) and asks a technical question about caching (hashes vs timestamps). This looks like a solid middle ground between npm scripts and a full-blown CI system. I've always hated the tab syntax in GNU Make, so a typed alternative is appealing.
I don't think you understand what he's proposing here. This isn't really a replacement for Make at all. This is just using Deno to run random script files.
That are two things in the article: having a kind of make alternative to "save your command history" and basically avoiding repeating large commands and how they use TS to make shell scripts.
This is one of Deno's killer use cases IMO. 100x better than shell scripting and like 5x better than Python scripting. Python should be good for this sort of thing, but it isn't.
Historically we had to use pip which was super janky. Uv solves most of pip's issues but you still do have to deal with venvs and one issue it doesn't solve is that you can't do imports by relative file path which is something you always end up wanting for ad-hoc scripting. You can use relative package paths but that's totally different.
> you can't do imports by relative file path
Just add the targeted path to sys.path, or write your own importhandler. importlib might help there. But true, out of the box, imports in python3 are a bit wacky for more flexible usage.
> 5x better than Python scripting
I’m not sure about that. All those ‘await’s, parentheses really kill my mojo. Why do you find it better than Python?
> Why do you find it better than Python?
I said already - the main reason is you can import files by relative file path.
You can get close to the Deno UX with uv and a script like this:
But you still have to deal with the venv e.g. for IDE support, linting and so on. It's just more janky than Deno.I wish someone would make a nice modern scripting language with arbitrary precision integers, static types, file path imports, third party dependencies in single files, etc. Deno is the closest thing I've found but in spite of how good Typescript is there are still a ton of Javascript warts you can't get away from (`var`, `==`, the number format, the prototype system, janky map/reduce design, etc.)
I use mise for this as it then also gives you a handy `mise tasks` command so you can see what commands are available and what they do. Mise has been a real gamechanger for my ailing memory.
Any good write up about this you can recommend please? I have been struggling to get on mise tasks train.
Zx is great. Really easy scripting!
This article used Dax instead which also looks fine! Https://github.com/dsherret/dax
There is also Bun shell built-in library, that I liked. https://bun.com/docs/runtime/shell
> I have definitelly crossed the line where writing a script makes sense
...and that was also the one concrete example where it makes sense to have extra dependency and abstraction layer on top of a shell script:)
say you know TS and even if you walk back to where $ is defined, can you tell immediately why $`ls {dir}` gets executed and not just logged?
You can make it more explicit by renaming the import to something like "shell_exec". Tagged templates are already pretty common in TS projects for things like gql or sql queries.
tagged template does not cause execution of given string. tagged template is just a function and in this case it's simply a proxy for console.log() which also doesn't cause execution of given string.
so how does it get executed?
unless it was just an example and you are supposed to switch in $ from some third party library... which is another dependency in addition to deno... and which can be shai-huluded anytime or you may be offline and cannot install it when you run the script?
Yes, it's another dependency (dax). The example with console.log is just that, an example. Standard dependency management practices apply, e.g. pinning a version/commit hash.
That explains it:) Maybe the original article deserves a clarification