Geoff Goodman

Geoff Goodman

@goodman.dev

Curious mind. Creator of https://plnkr.co. Tech lead for extensibility at Auth0 (OKTA). I will never stop experimenting.

73 followers119 following77 posts

Here's a demo of two aspects of MCP Auth. 1. Authenticating to an MCP Server in coordination with the MCP Host (VS Code Insiders). 2. Authenticating to a downstream service (Confluence) on demand for a tool, `confluence_search`. The MCP Host provides (1) but is oblivious to (2).

Sending unsolicited AI-generated email to the address scraped from my GitHub profile is not a growth hack, it's in violation of the CAN-SPAM act.

Some critical projects like @typescriptlang.org don't (or can't) follow SemVer. They suggest users pin versions in package.json. But what if npm package versions could explicitly *declare* their compatibility range. Clients could further constrain ranges for upon opt in. Best of both worlds.

I've seen folks looking to use AsyncLocalStorage as a way to propagate identity across async boundaries in server logic. That seems very scary to me because AFAIK it relies on 3rd party libs opting into AsyncResource or risking confusion in some edge cases. WDYT?

Geoff Goodman reposted

WinterTC is here 🎉 TC55 is a new Ecma Technical Committee for Web-interoperable Server Runtimes, originating from the existing W3C WinterCG group. This means the group is now able to publish standards, with the first effort being the Minimum Common API.

This seems like a fascinating innovation in load balancing but I feel like I didn't get a full picture from the talk: 1. Do the use the latency of the Probes or some aggregate of the Queries as predictors? 2. What if Queries are very heterogenous? 3. How do they derive predicted latency for RIF(n)?

Andrew Johnston@billywhizz.bsky.social

"This is what allows us to have the best of both worlds, most of the time: simultaneously routing based on latency and avoiding the highest-RIF replicas" www.youtube.com/watch?v=PSP3...

Here's my aspirational vision for a modelcontextprotocol.io (MCP) project. I'm pretty excited by the potential but the scope is _huge_. If you're unfamiliar with the MCP, it tries to standardize a protocol for clients like Claude, Zed editor, etc. to get extensible super-powers. WDYT?

Huge deal! It happened. I hope this will pull back the ESM CJS partition that crept in. Bravo @joyeecheung.bsky.social and collaborators!

Joyee Cheung@joyeecheung.bsky.social

🎉 require(esm) has been unflaged in v22.12.0! We are also planning to unflag it on v20.x later if it goes well in v22.x. As before please try it out and report any bugs you find. (hopefully none, but with how wild the module loading edge cases can be, one never knows!).

Geoff Goodman reposted

I bet OCI images (docker images) are a pretty perfect distribution format for MCP servers. As containers, we can abstract away dependencies while also isolating the host system as much as we want. And they should *just work* as stdio servers with the `-i` flag. Anyone already working on this?

I bet OCI images (docker images) are a pretty perfect distribution format for MCP servers. As containers, we can abstract away dependencies while also isolating the host system as much as we want. And they should *just work* as stdio servers with the `-i` flag. Anyone already working on this?

Geoff Goodman reposted

Here is a fun one for you all: contrary to popular belief, in Node.js promises (async/await) would not yield to the event loop. So, if you want the event loop to process I/O in between a long chain of async functions that actually aren’t doing I/O, you would need to add a setImmediate in between.

I think @anthropic.com's Model Context Protocol is fascinating. I've been re-implementing the stdio and sse protocols to understand the inner workings and am at the MVP stage. I'm exposing a custom weather tool that always responds with `"sunny with a chance of meatballs"` 🤣. Claude is onto me.

TIL that browser fetch doesn't allow duck-typed AbortSignal instances or Proxy instances that wrap real signals. Seems like a bit of a bummer for performant, interoperable AbortSignal tooling. Is this by design?

The very need for this makes me think it is evidence or a larger disconnect: package.json tries to encode metadata for three very distinct and sometimes mutually exclusive use-cases: 1. Developing the library / service / app 2. Consuming the library 3. Running the service / app

Lars@webpro.nl

✂️ What goes into dependencies vs devDependencies? Anyone wrote the go-to article? Could image there's like only a few clear strategies most projects could agree on. Jotted down this reply, but would be great to be able to link to something less scrappy/informal. → github.com/webpro-nl/kn...

View full thread

In a library with a build step, I'd love to see package.json be a generated file in ./dist, for example. With no build step, I imagine the shipped package.json being in a sub-directory that represents the to-be-shipped files of the larger project. Maybe workspaces already offer tooling for this?

Does this resonate with you? This is me trying to look at this through a systems lens, "What is the system at work that creates the need for this complexity?" I hope to start brainstorming by proposing some ideas but I'm in no way pretending that they're the *best* ideas. How would you tweak it?

The very need for this makes me think it is evidence or a larger disconnect: package.json tries to encode metadata for three very distinct and sometimes mutually exclusive use-cases: 1. Developing the library / service / app 2. Consuming the library 3. Running the service / app

Lars@webpro.nl

✂️ What goes into dependencies vs devDependencies? Anyone wrote the go-to article? Could image there's like only a few clear strategies most projects could agree on. Jotted down this reply, but would be great to be able to link to something less scrappy/informal. → github.com/webpro-nl/kn...

Overloading package.json with these different jobs-to-be-done is the sort of thing that leads to these other sub-optimal outcomes: 1. Massive docker images that include dev deps. 2. Inclusion of unwanted, inert files in `node_modules`. 3. Credential leaks meant only for dev that get co-opted in.

I have often wondered how to fix this and I'm not quite sure what strikes the right balance of trade-offs. But I think an workflow wherein the dev-time and prod-time metadata is isolated in different files is a good starting point.

Geoff Goodman reposted

TypeScript 5.7 is released 🎉 🔶 ES2024 library types 🔷 Checker: Never-initialized variables 🔷 Checker: Stricter JSON imports 🔷 Emit: Extension rewriting (*.ts to *.js) 🔷 DTS: Computed methods 🔷 IDE: Better tsconfig discovery 🔷 Perf: Code Caching ⚡️ 2.5x faster startup

TypeScript@typescriptlang.org

📢 TypeScript 5.7 is here! Now with ✅ Better checks for uninitialized variables ✅ Smarter tsconfig lookup in editors ✅ Improved startup time ✅ Stricter checks for JSON imports ✅ Extension rewrites for relative imports and more! Try it today! devblogs.microsoft.com/typescript/a...

What are the go-to tools for testing against memory leaks in JavaScript libraries? I'm particularly worried about an object graph being retained by circular references.

Geoff Goodman reposted

You know what feels terrible? Leading open source volunteers on a wild goose chase only to discover you were at fault all along. 😫

Geoff Goodman reposted

Google is an imperfect steward of Chrome, but I cannot think of anyone who'd have the capital to buy & run Chrome that wouldn't be worse in every way

Tom Warren@tomwarren.co.uk

US lawyers will reportedly try to force Google to sell Chrome and unbundle Android. It’s part of a DOJ case that aims to break up Google’s search monopoly by targeting Chrome, Android, and AI Overviews www.theverge.com/2024/11/18/2...

It's both a blessing and a curse to run high throughput, complex @nodejs.org workloads on the server. Blessing because there's lots of impact. Curse because we have a weird way of surfacing all the long tail weird issues in production.

I'm starting to think this way too but the muscle memory is brutal.

Haz@haz.dev

snake_case is much easier to read than camelCase, and I wish the JavaScript community agreed with me 🥲

You are up to date.