announcement tweet: https://xcancel.com/__tinygrad__/status/2039213719155310736

This is such a neat idea. I am going to adopt this for my own workflows as well, right now I just write private blog entries for stuff I do that I may forget how to do later (provisioning a server, networking, caddy setup, etc etc)

Thanks for sharing!

Doesn't zed use gpui?

I got somewhat addicted to the planning phase to the point I started getting task paralysis because I was hell bent on creating the perfect plan.

Everything can be optimized, performance can be improved, you can always think of more edge cases and user stories to cover everything, but after a point that just becomes procrastination in the form of chasing perfection. It's also hell if you've got even the slightest bit of ADHD, rapidly leading to task paralysis with the sheer scale of the plan.

Now I sit with a notebook sketch out everything I am thinking about and then condense it to a planning prompt and then once the plan aligns with my representation of the task, I start implementing.

I totally get where you're coming from with the planning loop. It can be a real trap because it always feels like you're making progress. The notebook idea is actually pretty clever. It lets you chill for a bit before you start involving the agent.

> rapidly leading to task paralysis with the sheer scale of the plan.

Yikes. I feel seen.

I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why).

Also from the report:

> Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, plain-crypto-js@4.2.1, a package that is never imported anywhere in the axios source, whose only purpose is to run a postinstall script that deploys a cross-platform remote access trojan (RAT)

Good news for pnpm/bun users who have to manually approve postinstall scripts.

> nearly every other project uses it for some reason instead of fetch (I never understood why).

Fetch wasn't added to Node.js as a core package until version 18, and wasn't considered stable until version 21. Axios has been around much longer and was made part of popular frameworks and tutorials, which helps continue to propagate it's usage.

Also it has interceptors, which allow you to build easily reusable pieces of code - loggers, oauth, retriers, execution time trackers etc.

These are so much better than the interface fetch offers you, unfortunately.

You can do all of that in fetch really easily with the init object.

   fetch('https://api.example.com/data', {
  headers: {
    'Authorization': 'Bearer ' + accessToken
  }

})

There are pretty much two usage patterns that come up all the time:

1- automatically add bearer tokens to requests rather than manually specifying them every single time

2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page.

There's no reason to repeat this logic in every single place you make an API call.

Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time.

Finally, there's some nice mocking utilities for axios for unit testing different responses and error codes.

You're either going to copy/paste code everywhere, or you will write your own helper functions and never touch fetch directly. Axios... just works. No need to reinvent anything, and there's a ton of other handy features the GP mentioned as well you may or may not find yourself needing.

Interceptors are just wrappers in disguise.

    const myfetch = async (req, options) => {
        let options = options || {};
        options.headers = options.headers || {};
        options.headers['Authorization'] = token;
    
        let res = await fetch(new Request(req, options));
        if (res.status == 401) {
            // do your thing
            throw new Error("oh no");
        }
        return res;
    }

Convenience is a thing, but it doesn't require a massive library.

That fetch requires so many users to rewrite the same code - that was already handled well by every existing node HTTP client- says something about the standards process.

It could also be trivially written for XMLHttpRequest or any node client if needed. Would be nice if they had always been the same, but oh well - having a server and client version isn't that bad.

Because it is so few lines it is much more sensible to have everyone duplicate that little snippet manually than import a library and write interceptors for that...

(Not only because the integration with the library would likely be more lines of code, but also because a library is a significantly liability on several levels that must be justified by significant, not minor, recurring savings.)

> Because it is so few lines it is much more sensible to have everyone duplicate that little snippet manually

Mine's about 100 LOC. There's a lot you can get wrong. Having a way to use a known working version and update that rather than adding a hundred potentially unnecessary lines of code is a good thing. https://github.com/mikemaccana/fetch-unfucked/blob/master/sr...

> import a library and write interceptors for that...

What you suggesting people would have to intercept? Just import a library you trust and use it.

But you said so yourself they are necessary… otherwise you would just use fetch. This reasoning is going around in circles.

Why the 'but'? Where is the circular reasoning? What are you suggesting we have to intercept?

- Don't waste time rewriting and maintaining code unecessarily. Install a package and use it.

- Have a minimum release age.

I do not know what the issue is.

but it does for massive DDoS :p

> Likewise, every response I get is JSON.

fetch responses have a .json() method. It's literally the first example in MDN: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

It's literally easier than not using JSON because I have to think about if I want `repsponse.text()` or `response.body()`.

that's such a weak argument. you can write about 20 lines of code to do exactly this without requiring a third party library.

Helper functions seem trivial and not like you’re reimplementing much.

Don't be silly, this is the JS ecosystem. Why use your brain for a minute and come up with a 50 byte helper function, if you can instead import a library with 3912726 dependencies and let the compiler spend 90 seconds on every build to tree shake 3912723 out again and give you a highly optimized bundle that's only 3 megabytes small?

> usage patterns

IMO interceptors are bad. they hide what might get transformed with the API call at the place it is being used.

> Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time.

This is not true unless you are not interfacing with your own backends. even then why not just make a helper that unwraps as json by default but can be passed an arg to parse as something else

One more use case for Axios is it automatically follows redirects, forwarding headers, and more importantly, omiting or rewriting the headers that shouldn't be forwarded for security reasons.

fetch automatically follows redirects, fetch will forward your headers, omitting or rewriting headers is how security breaks… now a scraper got through because it’s masquerading as Chrome.

What does an interceptor in the RequestInit look like?

A wrapper function around fetch… that’s what interceptors are…

It also supports proxies which is important to some corporate back-end scenarios

fetch supports proxies

Before that we had node-fetch. If you already use a dependency why not one that's pretty much what will come natively to every JS runtime soon.

The fetch API is designed for browsers. It's not designed for servers. Fetch may work for a particular use case on the server, it may not. Servers have needs over and above what a browser allows the client to do.

Now I'm curious, because we have a big server side code base using fetch(). What are you using that doesn't work with fetch? Especially since axios nowadays has a fetch adapter.

Right. Though I would've used the built in xhr then. Not going to install a dep just to make http calls.

> I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why).

You can remember this answer for every time you ask same question again:

"Coz whatever else/builtin was before was annoying enough for common use cases"

> (I never understood why).

I spent two years trying to get it out of a project that began long after Axios had become redundant but it's very hard to go back and challenge decisions like this because every business priority is aligned against this kind of work.

I expect libraries built on top of fetch will be the next to be compromised, because why would you use fetch without an arbitrary layer of syntactic sugar...

There was never the business value. But now remember this axios case and use it as ammo for the next issue. Just don’t abuse it

Does pnpm block postinstall on transitive deps too or just top-level? We have it configured at work but I've never actually tested whether it catches scripts from packages that get pulled in as sub-dependencies.

It prompts for transitive dependencies, too. I have never had workerd as a direct dependency of any project of mine but I get prompted to approve its postinstall script whenever I install cloudflare's wrangler package (since workerd needs to download the appropriate Workers runtime for your platform).

From what I can tell, it blocks it everywhere.

That's solid, really helps lock down the supply chain attack surface. Do you ever end up having to whitelist anything that legitimately needs to run on install?

After using pnpm for years (at least 5, don't remember exactly), I've only ever had to whitelist one library that uses a postinstall script to download a native executable for your system. And even this is not necessary, it's just poorly designed.

For example, esbuild and typescript 7 split binaries for different systems and architectures into separate packages, and rely on your package manager to pull the correct one.

> Good news for pnpm/bun users who have to manually approve postinstall scripts.

Would they not have approved it for earlier versions? But also wouldn't the chance of addition automatic approval be high (for such a widely used project)?

The prompt would be to approve the new malicious package (plain-crypto-js)'s scripts, too, which could tip users off that something was fishy. If they were used to approving one for axios and the attackers had just overwrote axios's own instead of making a new package, it would probably catch people out.

Assuming axios didn't have a postinstall script before, it wouldn't have been approved for a previous version. If you ignore it, you ignore it, but postinstall scripts are relatively rare in npm deps, so it would seem a bit out of place when the warning pops up.

>(I never understood why).

Because axios existed before the builtin fetch, and so there's a lot of stackoverflow answers explaining how to use fetch, and the llm models are trained on that, so they will write axios requests instead of fetch

spec: https://w3c.github.io/push-api/

A book on Janet⁰, a small and performant functional and imperative programming language.

⁰ https://janet-lang.org/

I don't know where that extra slash came from. https://facebook.github.io/memlab/ that's the actual link.

Sometimes HN does some auto formatting to submit links.

It's in the source repo (FB should fix):

  rel="canonical" href="https://facebook.github.io//memlab/"

Looks great! Love seeing Svelte being adopted in the wild.

I've been experimenting with jails on my devserver to sandbox AI agents, going to give this a whirl.

I would've given up on this project without Svelte 5! It’s so hard to justify React after using it. Proxmox always felt sluggish, but Sylve with Svelte stays smooth even on large clusters. DX is also much better. We started on Svelte 4 but moved early to 5 for things like runes.

Jails are great if your packages are in ports, and if not, Linux jails work well too: https://sylve.io/guides/deployments/rocky-linux-jail/, Haven't hit a CLI app that doesn't run in a FreeBSD Linux jail yet!

lastfm is still a great way to discover music, countless times I've gotten great recs from a music neighbor.