Comment by syhol | Hacker News Reader

Comment by syhol | Hacker News Reader

My gut reaction is to rush to the comments to shill my favourite task runner ( mise tasks[1], now with shell aliases[2]!) but pushing past that, the core idea of writing scripts in a file rather than a shell prompt is a great nugget of wisdom. But I disagree with this bit:

"I want to be clear here, I am not advocating writing “proper” scripts, just capturing your interactive, ad-hoc command to a persistent file."

What's the difference? Why not version control it, share it with colleagues. Imagine writing a unit test to test a new feature then deleting it when done, what a waste. Ok it's not exactly the same because you aren't using these scripts to catch regressions, but all of that useful learning and context can be reused.

I don't think the language you use for scripting is too important as long as the runtime is pinned and easily available on all engineers machines, perhaps using a toolchain manager like... mise[3].

[1] https://mise.jdx.dev/tasks/ [2] https://mise.jdx.dev/shell-aliases.html [3] https://mise.jdx.dev/dev-tools/

> What's the difference? Why not version control it,

Because I'm hardcoding directory paths.

Because I'm assuming things are set up a particular way: the way they are on my machine.

Because this is hardcoded to a particular workflow that I'm using here and now, and that's it.

Because I do not want to be responsible for it after no longer needing it.

Because I don't want to justify it.

Because I'm hard-coding things that shouldn't be checked in.

Because I don't want to be responsible for establishing the way we do things based on this script.

Do these scripts need to be productionised? I prefer working in an environment where efficient sharing of knowledge and solutions is encouraged, rather than framed as a burden of responsibility.

Given the choice between starting with an almost-working script or starting from scratch, I’ll take the former, it might save a few hours.

My colleagues and I don’t do this 100% of the time, but I never regret it and always appreciate it when others do.

Yeah, some of it can be solved as a simple naming convention thing. `_scripts/*.ts` for scripts that are "reproduceable" and/or production-ready and `_scripts/scratch/*.ts` or `_scripts/${username}/*.ts` for scripts that are piecemeal or work-in-progress or user-specific or otherwise "throwaway". Or a graduation process such as where things in `_scripts/` are considered "throwaway" until added to and documented in a larger production task runner like adding them to the "tasks" section of a deno.json file. (They graduate from being shebang run to `deno task taskname` run. They get basic documentation in the `deno task` list and various IDE integrations of such.)

The major thing to be concerned about there is leaking things like hard-coded secrets and that's where something like .env files can come in handy and knowing your tools to make use of them. Deno (as the running example) makes using .env files easy enough by adding the `--env` flag to your `deno run` shebang/task-line and then using `Deno.env` like any other environment variable. (Then don't forget to .gitignore your .env files.)

I don't understand this bit either, unless "proper" means Bash. Because no one should ever write Bash under any circumstances.

Reply on news.ycombinator.com