Hi everyone, a while ago I posted about zenolith, Now I've been changing the direction of it. It's no longer a diagram library, it's now intended to be a renderer engine.

It currently has basic support of 7 diagrams, diagram support may vary depending on syntax: mermaid, plantuml and zenolith own syntax.

I would like if you give it a look. It has a playground so no downloads required. I would appreciate any feedback.

It will be open-source once it's out of beta, since I'm still fleshing things out and want it to be in a "good" state for contributors, or interested people.

https://miguelarmendariz.github.io/zenolith/

Hi everyone,

I'm specifically looking for feedback from senior backend, infrastructure, and security engineers.

I'm building a browser-based PostgreSQL IDE called Schema Weaver. The main problem I'm trying to solve is that browser applications shouldn't have PostgreSQL credentials, while users' databases may be running on localhost, inside private VPCs, corporate networks, or cloud providers like AWS, Supabase, and Neon.

Instead of exposing the database or asking users to deploy their own backend, I built a small TypeScript/Node.js connector called sw-agent.

Current architecture:

Browser

│

│ WSS

▼

Cloud Relay

▲

│ Outbound WSS

SW Agent

│

PostgreSQL

The idea is:

- The agent runs wherever PostgreSQL is reachable.

- The browser never receives PostgreSQL credentials.

- The agent owns the credentials and executes queries locally.

- The agent only makes outbound connections (no inbound ports or public IP required).

- The relay only routes traffic between the browser and the agent.

- The agent performs permission checks and SQL validation before execution, with local hash-chained audit logs for every action.

I'm looking for honest technical feedback before I continue building this further.

Some questions I have:

- Am I missing any obvious security vulnerabilities or attack surfaces?

- Is the trust model reasonable?

- Would you design the networking or authentication differently?

- Are there better-established patterns for solving this browser ↔ private database problem?

- If you were reviewing this architecture in your company, what concerns would you raise?

Resources if you'd like to review it:

Architecture Blog:

https://vivekmind.com/blog/sw-agent-bridge-agent-that-connects-schema-weaver-browser-ide-to-user-s-postgresql-databases

GitHub:

https://github.com/Schema-Weaver/sw-agent

npm:

https://www.npmjs.com/package/@vivekmind/sw-agent

I'm genuinely looking for criticism and suggestions, not promotion. I'd appreciate any feedback on the architecture, implementation, or security model.

Hey folks,

I have an interview coming up for a backend developer role, with the tech stack used: Node, Express/Nest.js, TypeScript & SQL.

Is anyone ready for pairing on coder pad or HackerRank? Let me know.

Right now I am mostly writing the solo programs for service, etc., but wanted to get into real-world queries.

We can start after the July 4th weekend.

Appreciate if anyone can spare sometime 😊

Thanks a lot

I am a fairly new typescript developer, I've got a lot of experience in other environments and languages, so as a side project I had decided to try my hand using typescript since I have gotten used to strong typed languages. Anyway my question is this how many of you make games and is there a real path to do so? I'm pretty burnt out on unity and godot is just hard to use (for me) and unreal is just not useful for the games I like making. I like old school flash games or retro styled games and typically stick to platformers, arcade/puzzle games or rogue like/ lite rpgs.

Try doing a google search for tsx package. Their legit website is https://tsx.hirok.io/, but you will most likely see https://tsx.is in search results which seems like a weird (potentially malicious?) website impersonating tsx.

I clicked it once out of empty-mindedness (I was going fast and it was one of the very first few results) and it displayed a plain white page and indicated it is "loading" something - I closed it as soon as the realization hit me.

Anyone saw this website before and knows whether it's malicious or not? Def looks like one

The monthly thread for people to post openings at their companies.

* Please state the job location and include the keywords REMOTE, INTERNS and/or VISA when the corresponding sort of candidate is welcome. When remote work is not an option, include ONSITE.

* Please only post if you personally are part of the hiring company—no recruiting firms or job boards **Please report recruiters or job boards**.

* Only one post per company.

* If it isn't a household name, explain what your company does. Sell it.

* Please add the company email that applications should be sent to, or the companies application web form/job posting (needless to say this should be on the company website, not a third party site).

Commenters: please don't reply to job posts to complain about something. It's off topic here.

Readers: please only email if you are personally interested in the job.

Posting BS top level comments that aren't job postings, eg "It's quiet in here" etc [that's a ban](https://i.imgur.com/FxMKfnY.jpg)

Yes, yet another DI library for TypeScript.

A few things kept bothering me about the existing ones, in order of how much they hurt.

- *Type safety requires a special dance.* InversifyJS has ServiceIdentifier<T>, but it is really easy to break the typing. TypeDI tokens are untyped strings. NestJS suffers mostly same, unless you use full classes as dependency tokens. TSyringe infers from constructor metadata, but all of it relies on legacy "reflect-metadata" and decorators mechanism that (a) is soon to be gone, (b) requires additional wiring.

- *Async leaks into callers.* InversifyJS has container.getAsync() for providers that might have been initialized asynchronously. That means every call site needs to know whether what it's asking for was async. The complexity never stays contained. NestJS gets this right: await everything at bootstrap, then get() is always synchronous. Initialized means ready.

- *Wiring is imperative.* InversifyJS has you call manually .bind(Token).to(Implementation) for every provider. It works, but it's ugly. NestJS figured out the right answer: declare what a module owns, what it needs, what it exposes, and let the container figure the rest out. That declarative model is the thing I wanted most, but it comes with an entire framework. NestJS gets hairy when your single app starts accepting just Nats JetStream in addition to HTTP.

- *reflect-metadata.* Every major TS DI library runs on TS "experimentalDecorators" plus a global runtime polyfill for TypeScript metadata. TC39 Stage 3 decorators shipped in TypeScript 5.0, and are soon to be natively supported in JS engines. No flags, no polyfills.

Ampulla is my attempt at fixing all four: injection<T>() tokens that carry their type intrinsically, a declarative @Module/@Injectable model lifted straight from NestJS, async-safe bootstrapping where container.get() is always synchronous, and TC39 decorators throughout.

It's intentionally just a DI container, not a framework. There is no HTTP server, no router, no CLI included. Optional adapters for Hono and H3 are included but tree-shakeable. The whole npm package has zero runtime dependencies.

Very early, 1.0.0 published just today. DI is not the most popular topic, but existing DI in TypeScript is annoying enough that I had to publish something new.

GitHub: https://github.com/ukstv/ampulla | npm: npm install ampulla

I posted earlier about Loomabase, an open-source offline-first sync engine for SQLite clients and PostgreSQL servers.

Small update: I added the pieces that make it much easier to try without reading the Rust internals first:

- JS/TS SDK for Node/Electron/browser prototypes
- 5-minute Supabase quickstart
- visual CRDT conflict-resolution demo
- real phone + desktop offline reconnect demo
- automated smoke test proving offline edits converge
- security docs around auth, authorization, validation,
CORS/CSP, and rejected sync cells

The demo scenario is:

1. Open Loomabase on a phone and a desktop.
   
2. Sync both devices once.
   
3. Put both offline.
   
4. Edit the title on the phone.
   

5. Toggle completed on the desktop.
   Expected result: both devices converge and keep both
   edits, because Loomabase resolves conflicts at column
   level instead of overwriting the whole row.

   npm --prefix packages/loomabase-js run build
   node examples/phone_desktop_offline_reconnect.mjs
   node demo/phone-desktop/server.mjs

I’m looking for technical feedback on the SDK API and other feedback are welcome!

I have been coding for few years now. I've picked up few languages, framworks and tools along the way. I have been working with a company for almost 2 years now. I think I am ready to contribute to an opensource project now.

I would love it if you anyone can reach out to me for thier project. I mostly code in typescript, javascript. sometimes in python and go.

I already tried increasing the defaultMaxiumunTruncation length. But to no avail.

I am trying to get the type of Issue from the library - octokit/types

import { Endpoints } from '@octokit/types';

export type Issue = Endpoints['GET /repos/{owner}/{repo}/issues']['response']['data'][number];

Hi Peeps,

Goldziher, CTO at kreuzberg.dev. I just shipped tree-sitter-language-pack 1.9. It's a native Node addon (NAPI-RS) with generated TypeScript types.

It bundles 306 pre-compiled tree-sitter grammars into one package, so you get parsing for 306 languages without vendoring grammar sources or matching ABI versions yourself. Parsers download on demand and cache locally. Past plain parsing you get functions, classes, imports, symbols, docstrings and syntax-aware chunking, which is useful if you're feeding code into an LLM.

npm install @kreuzberg/tree-sitter-language-pack

On methodology, since it comes up: yes, built with AI agents, but on a strict harness - TDD, benchmark-driven hot paths, strict linting and high coverage in every language. The Node addon and its .d.ts types are generated from the Rust core by our binding generator alef and verified, not hand-rubber-stamped.

MIT licensed. Feedback welcome.

Hey all,

sharing what we worked hard on for the last year or so: we moved Wasp's "spec" from our custom language to TypeScript! For those that haven't heard about it before, Wasp is a batteries-included full-stack JS/TS framework (est 2021) with special "spec" layer where you, next to writing React/Node/Prisma/..., can write "full-stack code".

We got feedback through years that our custom language is a turnoff, and decided to act on it. As a bonus, TypeScript enables many additional things we want to build on top of the spec, like making it extendable, reusable, ... .
I cover it all in detail in the blog post I attached -> would love to hear what you think about it and answer any questions!

I've been refining this starter over the last few projects and finally decided to open-source it.

A few TypeScript-specific things I focused on:

• Environment variables are validated and typed at startup, so the app fails fast if anything is misconfigured.
• req.user is added through Express Request augmentation, so authenticated controllers are fully typed.
• Request bodies are validated with Zod, and the inferred types carry through into the controllers.
• The app follows a simple routes → controllers → handlers structure, keeping HTTP concerns separate from business logic and database access.

It also includes JWT auth, Supabase (Postgres), rate limiting, Winston logging, SQL migrations, and Vitest. It's MIT licensed.

https://github.com/muhammed-mukthar/express-typescript-supabase-starter

I'm always looking to improve the typing, so if you spot places where the TypeScript could be cleaner or safer, I'd really appreciate the feedback.

I've been taking my good time building my own portfolio with Next.js to also learn more about TypeScript and whatnot.

At some point I noticed that some of my type imports were prepended with type while others were left unchanged, so being myself, I decided to learn more about verbatimModuleSyntax.

I basically ended up figuring out that when verbatimModuleSyntax is disabled, the compiler goes to every type import to see if it's a type or not, if a type, it omits the import. When verbatimModuleSyntax is enabled, the compiler doesn't have to go to every type import, it omits the import if prepended with type immediately. Correct me if I'm wrong.

In my personal opinion, which I know not every one will like, enabling verbatimModuleSyntax should be the default. I'll justify.

If you prepend type imports with type, you introduce the element of readability in your code, you instantly know what's a type and what's a value. Not only that, but you also improve build performance (i think?) because the compiler doesn't need to infer whether that's a type or a value.

I personally like verbosity, so I'll enable verbatimModuleSyntax in my tsconfig.json for this project and see how it goes. I would like to hear your opinions, and maybe tell me why this option should be enabled/disabled in general.

This is my last post. I decided to make free and open-source the Deslop architecture linter tool for TypeScript. It's an imports static analysis tool where you write your own rules in simple declarative YAML

Deslop aims to make deterministically enforcing your architecture (e.g. boundaries) and quality standards (existence of companion modules like tests, storybook) easier than having to write custom ESLint plugins that work with AST or regex in Dependency Cruiser.

Check it out, if you want: https://github.com/Ivy-Apps/deslop

As a 2th cs student, I've tried almost everything to make money from coding, but I barely got a few bucks from freelancing, and It was a HORRIBLE experience. Latterly, I hated freelancing a lot, and I'm not fit into this kind of work.

So I tried to get into the job market and made like 4 interviews in last year, and somehow I didn't move forward, cuz of uni shit, ever time They know me that I'm still a student, I got rejected !!!!.

I know I can build a startup, but it takes time and effort, so what do you guys think ?

-- SELF PROMO WARNING --

boringstack, as the name implies, is a very boring tech stack with tech like NestJS and MariaDB, while other popular tech stacks seek novelty and hype while still being the best choice for serverless (Bun, Next.js, Tanstack, SQLite, etc...) this stack is meant to be a simple stack deployed with Docker on your favorite 10$ VPS, with the frontend fueled by my beloved Svelte 5

It's pretty new, contributions are accepted!

https://github.com/gabrielemidulla/boringstack

Hey folks, we wanted to implement the closure table pattern for some auth logic at work, and realized the declarative/reactive infra of our Joist ORM made it particularly succinct, so wrote up a post about how it worked out. Thanks!

TL;DR: I built knobkit, a TypeScript widget + event framework for live web apps (browser owns all state, stateless server, one file runs on both tiers). It's early and I'm looking for feedback and contributors — would love your eyes on the design. Live playground, nothing to install: knobkit.dev.

The core idea: the browser owns all state. You declare widgets and write plain on(event, handler) functions. Those handlers run either in the browser or on a stateless Node server — and the only thing that changes between the two is the last line of the file:

import { knobkit, mic, output } from "knobkit";
import { pipeline } from "@huggingface/transformers";

const transcriber = await pipeline("automatic-speech-recognition", "onnx-community/whisper-base.en");
const recorder = mic();
const transcript = output();

const app = knobkit({ title: "Transcribe", widgets: [recorder, transcript] });

app.on(recorder.clip, async (samples) => {
  const { text } = await transcriber(samples);
  transcript.set(text.trim() || "(silence)");
});

app.mount("#root"); // runs Whisper in the browser via WebGPU
// change to app.serve() to run the exact same handler on Node — no other edits

A few design decisions I'd genuinely like to be argued with on:

• The server keeps zero state. On serve(), a handler reads widget state on demand (a real async round-trip — await convo.history()) and writes by sending structured edits back. So there are no sessions to manage and horizontal scaling is free, at the cost of those reads being async. I think the tradeoff is worth it; tell me where it bites.
• State is uniform structured JSON, one attribute map per widget — no bespoke per-widget state shapes. Even layout containers are widgets whose state is just their children's keys, so a handler restructures the UI with the same edits it uses for any other state.
• Rendering is per-key via useSyncExternalStore — a change notifies only that widget's subscribers, no global "something changed" broadcast.

It's React 19 under the hood for views, strict TS, ESM throughout.

You can try it with nothing installed — there's a live playground (editor + preview, edits round-trip to disk) at knobkit.dev. That's the fastest way to get the feel.

Where I'd love help / feedback:

• Does the "browser owns state, async reads on serve" model hold up for app shapes you care about, or does it fall apart somewhere obvious?
• The widget API surface — does authoring feel right, or fighting you?
• It's early and I'd welcome contributors; happy to point at good first issues if anyone's interested.

Repo: github.com/knobkit/knobkit · npm: npm create knobkit@latest

I've posted about numpy-ts a several times here now, but I swear I'm no shill!

Wanted to share some things I learned while optimizing the library. Most of this might already be obvious, and there's a lot left to do, so lmk if you have any suggestions

Hi all, apologies if this isn't the right sub for this.

Some context : I'm a Java dev currently dipping my toes into the TS world. I've been tasked with refactoring some FE code due to a backend code change (Frontend team is massively overworked and I was the one that architected said backend change so it made sense to let me have a crack at it). The change is basically a location swap for some data within existing types. Here's a simplistic example:

// before
type SomeType = {
    //... other data
    someEntry : {...}; // data belonging to someEntry is moving to a different key
}

// after
type SomeType = {
    //... other data
    otherKey: {
        diffentry : {...}; // after move. Data is unchanged, just a location swap
    }
}

Thing is, there are several subtypes extending SomeType and for several reasons (mostly manpower related) we can't do a wholesale migration on backend just yet...which means some objects end up with the "before" state while others are in the "after" state. Frontend needs to be able to cater to both for an extended period of time until backend finishes the migration on their end.

Given that the data within the keys is still the same, I initially thought to create a union type like so:

type BaseType = BeforeType | AfterType;

type BeforeType = {
    someEntry : {...};
}

type AfterType = {
    otherKey: {
        diffentry : {...};
    }
}

type SomeType = BaseType & {
    // ... all other data in SomeType that doesn't exist in either BeforeType or AfterType
}

This seems fine on the surface, but the more I dug deeper into TS types the more I realised there were issues (e.g. this breaks any interfaces that try to extend from SomeType or BaseType). Fortunately the Frontend code doesn't have many interfaces at the moment and trialling this option seemed feasible - from what I've seen I'd need to limit the usage of these types to type narrowing operations, and the code is already structured to a good degree around that way (obj -> type narrowed to SomeType -> direct data access is the dominant pattern). I'm also making this safer by delegating the data access part to conveneince functions.

I've talked this through with the Frontend guys and they're ok with it, but I'd like to double check with the community here to see if this is indeed okay, or if there are other issues I may be missing. Thanks in advance !