inbx0 · HackerTrans

What do you mean by runtime? The JavaScript runtimes, like V8? Yeah those are impressively fast for a dynamically typed ”scripting” language, but that has little to do with TS. TypeScript’s work ends at compilation.

inbx0

9 ngày trướcdiscuss

For me, the main benefit is deployment bundle/artifact size reduction. Mostly from dropping unneeded files from node_modules. Many packages include both esm and cjs builds, sources, docs, TS types, etc. stuff that you don’t need in prod. This matters for lambdas, for example, because deployed code size has limits there.

inbx0

tháng trướcdiscuss

It's an interesting discussion, but I think simply outputting text can make the software "malware", even if the output isn't executable. What if the output was

  To use jqwik, please login to your Office 365 account:
  http://o365login.phishing.xyz

inbx0

2 tháng trướcdiscuss

Reminds me of the back and forth competition between Node.js and io.js that we had to endure back in the day. Worked out for the best in the end.

inbx0

3 tháng trướcdiscuss

minimumReleaseAge and lockfiles also pin down transitive dependencies.

inbx0

3 tháng trướcdiscuss

Number 1 would only be a win for zero-installs if it happened that registry was up when you made the security hotfix, since you'd need to install the depdencency the first time to get it in VC, but then suddenly down when doing a deploy. Seems like a highly unlikely scenario to me. Also, cases where npm CVEs must be patched with such urgency or bad things will happen are luckily very rare, in my experience.

Most npm CVEs are stuff like DDoS vulnerabilities, and you should have mitigations for those in place for at the infra-level anyway (e.g. request timeouts, rate limits, etc), or you are pretty much guaranteed to be cooked sooner or later anyway. The really dangerous stuff like arbitrary command execution from a library that takes end user input is much much more rare. The most recent big one I remember is React2shell.

Number 2 hasn't been much of an issue for a long time. npm doesn't allow unpublishing package after 72 hours (apart from under certain rare conditions).

Don't know about number 3. Would feel to me that if you have something running that can modify lockfile, they can probably also modify the chekced-in tars.

I can see how zero-installs are useful under some specific constraints where you want to minimize dependencies to external services, e.g. when your CI runs under strict firewalls. But for most, nah, not worth it.

inbx0

3 tháng trướcdiscuss

> Run Yarn in zero-installs mode (or equivalent for your package manager). Every new or changed dependency gets checked in.

Idk, lockfiles provide almost as good protection without putting the binaries in git. At least with `--frozen-lockfile` option.

inbx0

4 tháng trướcdiscuss

  - saves infra costs 
  - saves infra headaches 
  - devs only need to be experts in one system (or well I guess one and a half, probably there's something to learn about ParadeDB too, but probably less than in learning Lucine) 
  - no need to worry about keeping data up to date in the separate seach system
  - all data is available when you want to do new queries that you handn't thought of when implementing the data transfer/indexing

inbx0

8 tháng trướcdiscuss

At TypeScript-level, I think simply disallowing them makes much more sense. You can already replace .push with .concat, .sort with .toSorted, etc. to get the non-mutating behavior so why complicate things.

inbx0

8 tháng trướcdiscuss

I don't have much experience in dedicated vector databases, I've only used pgvector, so pardon me if there's an obvious answer to this, but how do people do similarity search combined with other filters and pagination with separate vector DB? It's a pretty common use case at least in my circles.

For example, give me product listings that match the search term (by vector search), and are made by company X (copanies being a separate table). Sort by vector similarity of the search term and give me top 100?.

We have even largely moved away from ElasticSearch to Postgres where we can, because it's just so much easier to implement with new complex filters without needing to add those other tables' data to the index of e.g. "products" every time.

Edit: Ah I guess this is touched a bit in the article with "Pre- vs. Post-Filtering" - I guess you just do the same as with ElasticSearch, predict what you'll want to filter with, add all of that to metadata and keep it up to date.

inbx0

9 tháng trướcdiscuss

Ehh what. I would give some merit to arguments like "no one should use lodash in 2025 because you can do most of it with built-ins nowadays" or maybe because it doesn't tree-shake well or maybe even because it doesn't seem to have much active development now.

But stating matter-of-factly that no one should use it because some of its well-documented functions are mutating ones and not functional-style, and should instead use one particular FP library out of the many out there, is not very cool.

inbx0

9 tháng trướcdiscuss

The post links to a TS issue [1] that explains

> As of TypeScript 5.0, the project's output target was switched from es5 to es2018 as part of a transition to ECMAScript modules. This meant that TypeScript could rely on the emit for native (and often more-succinct) syntax supported between ES2015 and ES2018. One might expect that this would unconditionally make things faster, but surprise we encountered was a slowdown from using let and const natively!

So they don't transpile to ES5, and that is the issue.

1: https://github.com/microsoft/TypeScript/issues/52924

inbx0

10 tháng trướcdiscuss

I don't think pinning deps will help you much, as these incidents often affect transitive dependencies not listed in package.json. package-lock.json is there to protect against automatic upgrades.

I know there are some reports about the lockfile not always working as expected. Some of those reports are outdated info from like 2018 that is simply not true anymore, some of that is due to edge cases like somebody on team having outdated version of npm or installing a package but not committing the changes to lockfile right away. Whatever the reason, pinned version ranges wouldn't protect against that. Using npm ci instead of npm install would.

inbx0

10 tháng trướcdiscuss

The main issue there is that the maintainer lost access to their account. Yanking malicious packages is better, but even just being able to release new patch versions would've stopped the spread, but they were not able to do so for the packages that didn't have a co-publisher. How would crates.io help in this situation?

FWIW npm used to allow unpublishing packages, but AFAIK that feature was removed in the wake of the left-pad incident [1]. Altho now with all the frequent attacks, it might be worth considering if ecosystem disruption via malicious removal of pacakge would be lesser of two evils, compared to actual malware being distributed.

1: https://en.wikipedia.org/wiki/Npm_left-pad_incident

inbx0

10 tháng trướcdiscuss

fzf [1] provides the TUI.

1: https://github.com/junegunn/fzf

inbx0

11 tháng trướcdiscuss

According to the description in advisory, this attack was in a postinstall script. So it would've helped in this case with nx. Even if you ran the tool, this particular attack wouldn't have been triggered if you had install scripts ignored.

inbx0

11 tháng trướcdiscuss

Periodic reminder to disable npm install scripts.

    npm config set ignore-scripts true [--global]

It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script.

I know this isn't a silver bullet solution to supply chain attakcs, but, so far it has been effective against many attacks through npm.

https://docs.npmjs.com/cli/v8/commands/npm-config

comments