A few years ago, I did the same and started unsubscribing from newsletters as soon as they arrived.
Now I keep only emails in my inbox that require action - everything else I archive or delete.
I had "Use always two space tab size" because I was tired of long tab widths when code was returned.
However, even when it wasn't about programming, I was reminded that the tab size would be two spaces ...
* Always use `-` instead of `–`, unless explicitly used by the user.
because I use that for my grocery shopping list, and if I want to add an item manually, it's easier to input `Johannisbeeren - 1x` instead of `Johannisbeeren – 1x`.
It resulted this
----
Me: "Tell me what's on TV tonight"
It: "I checked what's on TV tonight. For example, the spy comedy "Get Smart" [...]. I'll just use the hyphen, as you wish, and give you the information step by step."
It's just a thin wrapper for https://github.com/qasim/Airstream (I think it's very lame that the README doesn't mention this), which I think would work in a watchOS app although I'm not 100% sure it would get approved.
You should switch the default to not delete any files and modify/remove the files only with some flag (--dry-run=false, --rm, --delete, etc).
I just deleted all files accidentally in a monorepo :D
Luckily I didn't had any uncommitted changes and could recover using git
It's maybe reasonable to change the defaults, but I think you should also be mindful of running any random cli program in your codebase, the top of the Github readme does indicate that the --check mode runs it without deleting files.
I’d maybe recommend inverting the command so it doesn’t delete by default but only when you add the relevant flag. Far better to add a little rigmarole than deal with a sad person who wiped their code.
Besides, the common behavior is to do what it says on the tin by default, but offer flags to make cli's "simulate" their run with "--dry-run" or similar.
I'm not sure I know of any utility that would have the opposite behavior than that.
Well, explosives. They do in fact explode (what it says on the tin) but you have to put in some effort to make them do so. Similar to wiping out your codebase when testing an app. Personally I think developer will reduce support load from angry people by adding guardrails. Someone will not have committed their code.
An alternative is to have a check “Are you sure?” Just before delete, with a -fuckit_yolo flag to override the check.
I once had a desktop app and realised over a while that just making copious backups (50, IIRC) meant users were less likely to get angry when they had lots of extra safety, even from their own actions.
I guess the "explosives" in this analogue could be deleting files with "unlink", "rm", "find -delete" or "shred", neither of which require a flag to actually perform the job they're meant to perform.
> An alternative is to have a check “Are you sure?” Just before delete, with a -fuckit_yolo flag to override the check.
Alternatively, is there any point you'd run this "ts-remove-unused" tool and you don't want it to delete anything? The main point of the tool is to delete things, so not sure what other use cases you have if you don't want it to delete something.
The "install -y" pattern is kind of similar. Various tools have as a default that it gives a list of packages that would be installed, and then ask for confirmation.
A "Hey, this is really going to delete files. If you're just playing around here, maybe try it with the --dry-run flag" seems sane and (so long as it's asked for) means less syntax to have to know up front.
You're totally right. I just quickly scanned the readme and had expected a tool that only check the files. But yes, it's a bad idea in general to run random cli programs without checking them in detail
I’m sorry that it may have been unclear that the tool will make modifications without the check flag. I’m glad you didn’t loose any unstated changes :)
I will add a cautionary note to README to make it clear!
Isn't the name kind of a giveaway that it does more than just checking? "ts-remove-unused" is plastered all over the place, and you need to even type/paste the name into your terminal before you can use it.
Don't people do that all the time? I doubt that even you check everything that you run thoroughly. There's a lot of trust we have put into all those tools.
It would be kinda cool to use git status to avoid accidental data loss for tools like this.
I've never interacted with git programatically so I don't know how messy it would be to implement. But for tools that mostly operate on "whole files" rather than lines in files, I guess it shouldn't be that tricky?
It’d be very easy to programmatically check which files in a repo directory are unknown to git. Git status does indeed have a machine-parseable output mode.
I'm trying to achieve something similar with SignalDB: https://signaldb.js.org/
It uses signals for reactivity and is framework agnostic with a mongodb-like query syntax
