https://stackoverflow.com/questions/79941971/how-to-enforce-server-side-file-validation-when-using-supabase-storage-client-si

JSBin was down for quite a few days and I realized how much I depended on it. It was my scribble pad, quick note taker, place to think out loud, & my goto tool for testing scripts and UI ideas fast.

So I did what any sane dev would do…

I built it from scratch T_T

TSBin can run offline as well, everything is stored locally, you get intellisense and emmet for HTML & CSS

Let me know in the comments what more features should I add !

Hi there guys. I was experimenting around for few weeks and made this new TS/JS runtime.

It is not production ready yet. But you can play around and see how it is different from Node, Bun and Deno.

https://github.com/RtlZeroMemory/Sloppy

Here is short TL:DR

Sloppy is trying to bring a more serious, batteries included development experience to the JavaScript ecosystem, closer to what developers expect from .NET or Java/Spring.

It is not trying to be another Node/Bun/Deno clone. The idea is different: runtime + framework + compiler-aware tooling, built together.

Sloppy includes, or is actively building toward:

* pre-compilation and static runtime metadata
* compile-time checks for routes, contracts, ORM models, and framework metadata
* HTTP routing and request/response handling
* OpenAPI/contracts
* authentication and authorization
* logging, health checks, metrics, and management endpoints
* first-party ORM and migrations
* background jobs / scheduler
* cache and output cache
* WebSocket / realtime primitives
* WebHooks 
* HTTP client factory with resilience policies
* Streaming API's 
* Cursor based data streaming from database 
* Redis integration
* TestHost and TestServices for serious integration testing

Ask any questions and clarifications in comments, i will gladly answer.

This project will keep growing/improving and being maintained.

Some feedback would be appreciated

A feel days ago I posted a CLI that converts OpenAPI specs into MCP servers. The feedback here was brutal and exactly what I needed.

Here's what I actually fixed and shipped based on your comments:

The original post got two pieces of feedback that changed the project:

"Raw endpoints wrapped as tools is a poor LLM interface pattern" — Fair. The generator now produces a scaffold you're supposed to implement, not ship. Incremental generation (@@mcp-gen:start/end markers) means you regenerate without losing your handler logic.

"console.log leaking into stdio corrupts the JSON-RPC stream" — This was a real bug. Fixed with a log() helper that writes to stderr and a safeSerialize() that handles Buffer/Uint8Array as base64 before anything touches stdout. Circular $ref schemas were the next wall — fixed with SwaggerParser.dereference({ circular: "ignore" }) + a visited-Set guard in the schema walker.

What shipped in v2.0.0:

YAML input (.json, .yaml, .yml, URLs) Python/FastMCP + Pydantic v2 target Incremental generation — re-run the generator without losing custom handlers oneOf/anyOf/discriminator support for complex specs Auth stubs from securitySchemes Interactive CLI mode for first-time users Built-in registry: mcp-gen init --from stripe (10+ APIs: Stripe, GitHub, Slack, OpenAI, Twilio, Shopify, Kubernetes, DigitalOcean, Azure) stdout isolation + safe binary serialization Circular $ref safety Published on npm and pip

Use cases:

Give Claude instant access to any REST API in under 2 minutes Generate internal API MCP servers for your team Rapid prototyping — have a working server before writing a single handler API-first development — spec first, scaffold second, logic last

2-minute setup:

npm install -g mcp-gen mcp-gen init --from stripe --out ./stripe-mcp cd stripe-mcp && npm install && npm start

Then add it to claude_desktop_config.json and Claude has full Stripe access.

GitHub: https://github.com/ChristopherDond/MCP-Generator npm: https://www.npmjs.com/package/mcp-gen Install: npm install -g mcp-gen

Questions? Want to contribute? Drop a comment or check out CONTRIBUTING.md on GitHub: https://github.com/ChristopherDond/MCP-Generator/blob/main/CONTRIBUTING.md

Still a lot to do — oneOf edge cases, better binary streaming, more registry entries. If you find a spec it chokes on, open an issue.

Thanks for all feedbacks and stars!!!

Talking about Node.js, a big problem we face today is that using the most popular libs like Nest.js and others, we end up with a crazy amount of dependencies we never actually chose to use. And when one of them gets flagged with a vulnerability, it flows up the chain until it hits our installed lib - and boom: update fast or your app is vulnerable.

I know it's basically impossible to avoid this problem while still keeping a decent set of tools that make our lives as devs easier. After all, these libs were created to encapsulate complex problems so we can focus on the actual business logic.

Anyway, this problem still sucks, and an interesting approach is to build no/low-deps projects - or more precisely, projects with minimum and audited dependencies. Like using Fastify instead of NestJS, or Drizzle instead of Prisma.

I started thinking seriously about this after I created a robust [NestJS boilerplate](https://github.com/vinirossa/nest-api-boilerplate-demo) for my future projects, with all the enterprise features I see at work - so I'd never have to start from scratch and debug "foundational" features like RBAC, i18n, caching, etc.

Now I'm thinking about building a similar boilerplate using a low-deps stack - same feature set as much as possible, but with a lighter and more audited dependency footprint. Think Fastify, Drizzle, postgres.js and Zod instead of the heavy hitters. That said, I'm aware this isn't a silver bullet - reimplementing things manually also opens the door to vulnerabilities, and those tend to fly under the radar since there's no CVE tracking or community eyes on your custom code.

What's your experience with no/low-deps projects? I'd love to hear more about it.

https://github.com/srtdog64/zeno

Hi,

I’m a beginner developer from Korea, and I’ve recently been working on a small TypeScript project.

Zeno is a code generation tool that turns schema-only TypeScript interfaces into DataView-backed accessors for fixed-layout binary records in ArrayBuffer. The goal is to make binary metadata easier to read and maintain in browser, WebGL, worker, and renderer-buffer pipelines without manually managing byte offsets everywhere.

I built it because I wanted a way to serialize and read metadata for a WebGL game. The main focus is WebGL performance. My goal is to make WebGL-related metadata easy to pass around, read in the browser, and eventually feed into an AI system.

The reason is personal: I really want to play tabletop-style games, but I do not have people around me who can play with me regularly. So I am currently building a WebGL game with a dungeon master and players, and I would like to use AI as the dungeon master.

I work mostly as a freelance developer, so I have not had many chances to be part of a code review culture or a larger engineering team. Because of that, it is difficult for me to judge the quality of my own code. The project works for my own use case, but I do not yet know how it looks to other TypeScript developers.

I would be grateful if people in the TypeScript community could take a look, try it if it seems useful, and give me feedback or code review.

This is a passion project I was theorycrafting and implementing for the last two years.

https://wraplet.dev

https://github.com/wraplet/wraplet

The goal was to make a low-footprint framework that would:

1. Take full advantage of OOP with declarative dependency structures, where objects' implementations can be freely switched out.
2. Take full advantage of TypeScript, which infers types based on these structures.
3. Could work with **any** DOM structure (elements, classes, attributes, etc.: you should be able to bind your behaviors to anything that is out there).
4. Removes the hassle of lifecycle management.

I wanted to have the flexibility of writing vanilla JS but in an environment of the best programming patterns that would prevent the code from becoming a mess over the long term.

This is not an alternative for React but rather for jQuery. According to w3techs market share of jQuery is still significant: https://w3techs.com/technologies/details/js-jquery

Wraplet allows for a gradual migration to a much more maintainable structure, but it also works for new projects that render HTML server-side (I think Wraplet fits popular CMSes especially well).

I think there was an uncovered middle ground between imperative jQuery code and full SPA solutions. This is what Wraplet covers.

The docs have many interactive examples.

Actually, I made a separate library: `exhibitionjs` just to showcase `wraplet`.

If you also develop online docs and don't like dependency on external sandbox providers, you can look it up at: https://exhibitionjs.wraplet.dev/ Of course, it's wraplet-powered.

Ok, that was me; now it's time for an AI slop, because it's actually pretty decent at readable descriptions, or at least better than me.

AI SLOP STARTS

Introduction

wraplet is a small JavaScript/TypeScript framework for projects that still work directly with the actual DOM (server-rendered apps, jQuery legacy, multipage sites, plain HTML, libraries shipping DOM components, etc.).

Instead of replacing the DOM with a virtual rendering layer, wraplet lets you bind class instances ("wraplets") to real DOM nodes and gives you:

• a predictable lifecycle (construct -> initialize -> destroy),
• a typed, declarative dependency system between components (required/optional, single/multiple),
• automatic event listener cleanup via NodeManager,
• automatic wraplet creation/destruction when DOM nodes appear/disappear (NodeTreeManager),
• components that are trivial to unit test - each wraplet is just a class around a node.

Pros:

• Plays well with backend-rendered HTML. No "the framework owns the page" mindset.
• TypeScript-first. Types describe component structure, not just APIs.
• Tests are boring (in a good way). A wraplet is a class with a node. new MyWraplet(element), call methods, assert. No JSDOM-heavy framework setup.
• Encapsulation by default. Parents talk to children through methods like setError("..."), not by reaching into their internal nodes.
• Gradual adoption. You can migrate a single jQuery-based widget without touching the rest of the app.

Where it's a good fit:

• progressive modernization of legacy jQuery / server-rendered UIs (PHP, Rails, Django, Laravel, etc.),
• libraries that ship reusable DOM-bound components,
• projects where a full SPA would be overkill,
• teams that prefer classes, encapsulation, and explicit relationships.

Where it's not a good fit:

Apps already happily built on React/Vue/Svelte - wraplet is not competing with them; it's solving a different problem.

TypeScript as a first class citizen

Most "DOM-binding" libraries treat TypeScript as a coat of paint on top of a runtime API. Wraplet tries to use TypeScript as the actual architecture layer - the place where you express what a component is, what it depends on, and what shape those dependencies have. The runtime then derives behavior from that.

The component is a generic class parameterized by the wrapped DOM node

In the simplest case, the type describes what type of node is wrapped by the wraplet:

import { AbstractWraplet } from "wraplet";

class Button extends AbstractWraplet<HTMLButtonElement> {
  protected async onInitialize() {
    // `this.node` is HTMLButtonElement, not Element, not unknown.
    this.node.disabled = false;

    this.nodeManager.addListener("click", (e) => {
      // `e` is properly typed as MouseEvent.
    });
  }
}

But the real fun begins when we introduce dependencies with the `DependentWraplet`.

The dependency map is the type

A wraplet that has children declares them through a plain object that is also a literal type:

import {
  AbstractDependentWraplet,
  type WrapletDependencyMap,
  type DependencyManager,
} from "wraplet";

const map = {
  submit: {
    selector: "[data-js-form__submit]",
    Class: SubmitButton,
    required: true,
    multiple: false,
  },
  fields: {
    selector: "[data-js-form__field]",
    Class: Field,
    required: true,
    multiple: true,
  },
  errorBox: {
    selector: "[data-js-form__error]",
    Class: ErrorBox,
    required: false,
    multiple: false,
  },
} satisfies WrapletDependencyMap;

class Form extends AbstractDependentWraplet<HTMLFormElement, typeof map> {
  protected async onInitialize() {
    this.d.submit;    // SubmitButton          (required + single)
    this.d.fields;    // WrapletSet<Field>     (required + multiple)
    this.d.errorBox;  // ErrorBox | null       (optional + single)
  }
}

A few things worth highlighting from a TS perspective:

• satisfies WrapletDependencyMap keeps the literal types (concrete Class references, concrete required/multiple booleans) while still validating the object against the framework's contract.
• typeof map is then passed as a generic parameter to AbstractDependentWraplet, so the framework can compute the type of this.d per-key:
  • required: true, multiple: false - T
  • required: false, multiple: false - T | null
  • required: true, multiple: true - WrapletSet<T>
  • required: false, multiple: true - WrapletSet<T> (possibly empty)
• Renaming a key in the map updates the type of this.d.<key> everywhere. Renaming a child wraplet class propagates through the parent's type. "Find usages" actually finds usages.

The dependency map effectively becomes a typed schema of your component tree. The runtime DependencyManager queries the DOM, instantiates the right classes, and hands them back to you typed exactly as the map describes.

Async lifecycle with typed extension points

onInitialize and onDestroy are well-defined hooks; listeners and child wraplets are tied to that lifecycle, so cleanup is automatic. Lifecycle listeners on dependencies are also typed to the dependency they are attached to:

dm.addDependencyInitializedListener("fields", async (field) => {
  // `field` is `Field`, inferred from the map key "fields".
});

Custom injectors - typed too

If for some reason a child shouldn't receive its own DOM node directly (e.g. you want to wrap it in something), you can declare a custom injector on a dependency. The injector's callback is typed against the wraplet's expected constructor input, so a mismatch is a compile error rather than a runtime surprise.

What this enables practically

• Refactoring with confidence: changing the structure of a component (adding/removing a child, switching from single to multiple, making something optional) is a typed change. The compiler walks you through the consequences.
• Encapsulation by types, not by convention: parents only see the public methods of their children. There's no implicit "reach into the inner DOM of my child" ? you'd have to add a public method on the child wraplet, which is exactly what you want.
• Tests are just new MyWraplet(node): no framework runtime to boot, no JSX renderer, no JSDOM gymnastics beyond having a node. Types make sure the test is constructing the component correctly.

AI SLOP ENDS

Writing this framework (and docs with examples) was a bumpy road, but I hope it will be useful for some of you. If you are still reading this, thanks for sticking with me. 😄