[jasonlotito]

> 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.

[syhol]

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.

[WorldMaker]

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.)