I appreciate that the project acknowledges its inspiration. I wish it were more common for projects to provide detailed comparisons with similar ones for people trying to choose.
Broken promise 1 (Automatically generating CHANGELOGs) is spot on, especially in a monorepo with multiple released artifacts. A single commit could be a breaking change in one package and refactor in another. But the changelog tools see one commit and include it in both changelogs.
Another issue is that once the commit lands on trunk, you can’t revise the entry without editing history. You have to remember to fix it after the changelog is generated.
Yeah, that's my immediate debate in reading this blog post: `deno pack` might be a great replacement to my existing `npm publish` workflow for my open source packages and continue shifting my work to Deno-first/Deno-mostly, but on the flipside, with Node's growing TS support I'm also considering switching to Typescript-only npm packages as a (tiny) message to the ecosystem.
Though I'm also happy that JSR exists as that (mostly) cleaner ecosystem.
> Currently there is consensus that Node.js should NOT run TypeScript files inside `node_modules. It is not supported to avoid package maintainers to release TS only package.
It sounds a lot like DNT (https://github.com/denoland/dnt) which has existed for a long time, but having it in Deno cli does bring significant visibility.
Git worktrees are awesome but they broke my workflow in a couple ways:
Resuming work. I used to `j <reponame>` then `gco <branchname>`. Now if I do that I get an error about the branch being checked out already in another worktree. I realized the branch names are pretty unique across repos so I made ` jbr <branchname>` that works from anywhere.
Jumping within repo. The other kink was when I wanted to focus on a particular package I’d do `j <subdir>` and it would usually be unique enough to jump to the one in my current checkout. But now I have dozens of concurrent checkouts and have to pick, even though I’m already in the repo. So `jd <subdir>` does like autojump or zoxide but only within the current checkout.
To power those shell functions I made a “where” extension for Git.
I was on a date when she asked “do you like magnetic fields?”. “Yes!” and we were both smitten.
Took us a few conversational turns to realize we had different capitalization. (This was in the old days when courting was mostly by speaking in person.)
Key differences seem to be resumable transfers and proxy support.
Another is a single binary, whereas MW is in Python, but there’s now https://github.com/magic-wormhole/magic-wormhole.rs
I appreciate that the project acknowledges its inspiration. I wish it were more common for projects to provide detailed comparisons with similar ones for people trying to choose.