frankdejonge

4 mesi fadiscuss

I've used it but recently moved back to plain claude code. We use claude at the company and weirdly the experience has become less and less productive using opencode. I'm a bit sad about it as it was the first experience that really clicked and got great results out of. I'm actually curious if Anthropic knows which client is used and if they negatively influence the experience on purpose. It's very difficult to prove because nothing about this is exact science.

frankdejonge

9 mesi fadiscuss

For node applications, startup time is impacted by IO a many files is less nice for IO wait times. So bundling does make a material impact for non-bundled backend applications and large libraries. I do agree, most impact is had when using bundling at a moment closer to the deployment.

frankdejonge

9 mesi fadiscuss

I use it to compile backend code. For those use-cases, IMO, vite itself is not so interesting (although I do use vitest). Using tsdown gives me a simplified API to compile my BE code so I can publish it to NPM. Nothing more nothing less. It’s faster and less work to orchestrate using TSC for CJS and ESM output, so very high ROI for me.

frankdejonge

9 mesi fadiscuss

I’m using tsdown for a collection of packages and am switching a current project (https://flystorage.dev)over to it. I use it in “unbundle” mode, which doesn’t bundle but does file for file transpilation. To me, it’s an opinionated rolldown configuration with a simplified API. You can script up in a couple of lines of code which packages in a monorepo to compile and what formats to compile for. An example of that can be found here: https://github.com/duna-oss/deltic/blob/main/tsdown.config.t...

Compared to using plain tsc to compile the code, is that it’s a lot quicker. The compiled code has some odd conventions, like using void 0 instead of undefined, but … whatever works!

So far, it has been an easy-entry high-ROI tool that helps me publish TS/JS tools quite easily.

frankdejonge

10 mesi fadiscuss

Resolving by hash is a half solution at best. Not having automated dependency upgrades also has severe security downsides. Apart from that, lock files basically already do what you describe, they contain the hashes and the resolution is based off the name while the hash ensures for the integrity of the resolved package. The problem is upgrade automation and supply chain scanning. The biggest issue there is that scanning is not done where the vulnerability is introduced because there is no money for it.

comments