Founder of Hex16, a small web studio in Poland. I build Next.js sites and headless Shopify stores, with GSAP, Three.js and shaders where they earn their place, and look after technical SEO.
Mine is a cousin of #3. The package exists and is popular, it just pulls in a pile of dependencies for something that was fifteen lines of code. I accepted one from an agent without looking. The 30-second check: git diff --stat on the lockfile. If it grew by hundreds of lines for a small feature, ask why.
Software Engineer · Next.js · React · TypeScript · Three.js · Node.js · Spring Boot · MySQL · WordPress · Shopify · Claude Code · Codex · Building tools to make your daily dev work easier
Thank you, that's a good addition to #3. The package is real, so nothing looks wrong, and the cost only shows up in the lockfile. Checking the lockfile's line count is a quick way to catch it. When this happens to you, do you usually swap the package for a few lines of your own code, or look for a smaller package that does the same job?
Founder of Hex16, a small web studio in Poland. I build Next.js sites and headless Shopify stores, with GSAP, Three.js and shaders where they earn their place, and look after technical SEO.
Depends on what it does. If it's formatting or a small helper, I write the fifteen lines myself and add a test. For dates, parsing or anything crypto I keep a well-known library even if it's heavier, because there my fifteen lines would be the bug. The smaller lookalike package is the option I trust least, a lot of them have one maintainer and no release in years.
Software Engineer · Next.js · React · TypeScript · Three.js · Node.js · Spring Boot · MySQL · WordPress · Shopify · Claude Code · Codex · Building tools to make your daily dev work easier
Thank you, that's a sensible split. Your point about lookalike packages is a good one. Before I accept a package an agent suggests, I'll start checking its last release date and number of maintainers on npm. That takes about ten seconds.
We're a place where coders share, stay up-to-date and grow their careers.
Mine is a cousin of #3. The package exists and is popular, it just pulls in a pile of dependencies for something that was fifteen lines of code. I accepted one from an agent without looking. The 30-second check: git diff --stat on the lockfile. If it grew by hundreds of lines for a small feature, ask why.
Thank you, that's a good addition to #3. The package is real, so nothing looks wrong, and the cost only shows up in the lockfile. Checking the lockfile's line count is a quick way to catch it. When this happens to you, do you usually swap the package for a few lines of your own code, or look for a smaller package that does the same job?
Depends on what it does. If it's formatting or a small helper, I write the fifteen lines myself and add a test. For dates, parsing or anything crypto I keep a well-known library even if it's heavier, because there my fifteen lines would be the bug. The smaller lookalike package is the option I trust least, a lot of them have one maintainer and no release in years.
Thank you, that's a sensible split. Your point about lookalike packages is a good one. Before I accept a package an agent suggests, I'll start checking its last release date and number of maintainers on npm. That takes about ten seconds.