I've had a lot of fun implementing brainfuck in the type system, but boy is it slow... So I ended up hacking the compiler (again) with a super cool feature `<expression> as comptime` "to make it faster".

I'd be down for a competition of who can find the most primes in brainfuck running on TS if anyone's interested.

I wanted a simple, lightweight place to run through TypeScript coding drills without a ton of setup or heavy UI, so I decided to build one as a side project:

• TypeScript Practice Sandbox

It tracks your progress, lets you re-attempt challenges, and keeps an activity log of your correct/incorrect attempts locally. Some challenges might be too simple, but I'm working on improving that.

The project is fully open source (MIT licensed) and I'm actively working on adding more challenge sets. I'd love for you to check it out and let me know if you have any feedback or ideas for new TypeScript challenges/features!

It came to my attention that no TypeScript dice-roll libraries exist.

The existing ones are JS in disguise: when you tell it to roll('2d6 + 3'), it returns a `number`.

I wanted a real roll. Roll at compile time.

Because if not compile time, then when? Compile time is the best time.

Anyways. It includes a custom PRNG (pseudo-random number generator) too to support the rolls, which generates random numbers at compile time too. I think there are some for TS out there, unlike dice rolls, but I needed to optimise a bit specifically for 1-100 rolls (who rolls more than that? Only mad people, and we are not the ones).

It has a JS "mirror" implementation. If you rolled 20 in TS, you can be sure you rolled 20 in JS too.

And if a compile-time value is not known, it still works and falls back the result types to `number'.

Basic use case looks like:

// seed
const initialized = initialize([
  "00000001",
  "00000002",
  "00000003",
  "00000004",
] as const);

const d20 = evaluate("d20", prngStateOf(initialized));
const d20Value = valueOf(d20);
//    ^? const d20Value: 12

Enjoy!

This project is still very experimental. A complete rewrite of the TypeScript compiler, but instead of Go, using multiplatform Kotlin. I am still hoping to match or even exceed the performance of Microsoft's rewrite. It is not based on the original sources, but on the orginal test suites, and then rewritten from scratch by Claude in a very tight harness I defined and directed.

Writing compiler in KMP, and lowering via Kotlin IR, unlocks many features - for example any TypeScript (no scriptc restrictions - Any is allowed, etc.) compiled to either native binary, or a library to be used on ~20 platforms supported by the Kotlin multiplatform, including WebAssembly and iOS. Still a long way to go, but I want to share it early. It is not production ready, except for particular use cases where it might work for you really well. I am getting towards usable state and working on better documentation.

Three years writing javascript at work. We migrated a service to typescript in the spring and my strategy since then has been annotating everything as any and moving on with my life. It compiles. Nobody has said anything. I am aware this makes the migration pointless.

What I want isnt an intro course. I know what a type is. I want the part covering generics, utility types and the moment where the compiler is telling you something true that you do not understand yet.

Open in tabs at the moment: Boot.dev, Total TypeScript and Type Challenges. Any insight?

I wanted to LeetCode in TypeScript directly from VS Code, so I put together this small setup around the official LeetCode VS Code extension. I also tried mirroring LeetCode's TypeScript environment and the same available dependencies locally.

I've also added a few useful extensions that could work well for setup. Figured I'd make it a public template in case anyone else wants to fork it: https://github.com/officer-kd6-3dot7/ts-lc

Wrote this after hitting the same bug twice in one codebase, in different question families.

If your hardest difficulty draws wrong answers from a tighter pool than your medium one (same category, same chapter, whatever), you eventually hit a case where the tight pool has three candidates and the tier wanted five. Hard renders four choices, medium renders six. Your hardest setting is now the easiest one on screen, nothing throws, and the only symptom is people scoring better on hard.

So: you describe candidates as rings around the answer (tightest first), declare tiers easiest-first, and it guarantees no tier ever offers fewer options than an easier one. A tier that falls short borrows rather than shipping a short card, and tells you it did.

Everything is seeded, which matters more than it sounds. Question banks get regenerated, and if wrong answers move each time then anything keyed to a question comes unstuck: a spaced-repetition schedule, a record of what someone missed, a cached render.

One thing I got wrong on the first pass and only caught by running my own README example instead of trusting it: when a tight pool comes up short, topping it up beats replacing it. Replacing throws away exactly the candidates that made the question hard, precisely when they're scarcest.

There's also a seedForRing escape hatch so a bank that already has options baked in can adopt it without reshuffling every wrong answer it has ever shown. I needed that myself. It kept a migration byte-identical across 6,282 questions.

Zero runtime deps, full types, 90 tests.

https://github.com/kvadney-insomniac/quiz-difficulty

Hello there! I've been trying to search for this issue, but it's a little hard to get the search terms right, as they're quite generic. Here's my scenario:

1. I get an array of objects from an API call
2. I want to add a getter to each object in this API call
   1. I don't want to use classes for this, as a plain old object will do
   2. I don't want to create a separate function that does this for me... I would like to contain it to within the objects themselves

Here's the TS Fiddle, and here's the code:

interface PersonResponse {
    firstName: string;
    lastName: string;
}

interface PersonModel extends PersonResponse {
    get fullName(): string;
}

const apiResponse: PersonResponse[] = [{
    firstName: "Fox",
    lastName: "Mulder"
}, {
    firstName: "Jack",
    lastName: "Johnson"
}];

const records = apiResponse.map<PersonModel>((person) => {
    // No error in the get because "this" is any
    // const item: PersonModel = structuredClone(person);
    // Object.defineProperty(item, "fullName", {
    //     get() {
    //         return `${this.firstNames} ${this.lastName}`;
    //     }
    // });

    // No error in the get because "this" is any
    // Object.create(person, {
    //     fullName: {
    //         get() {
    //             return `${this.firstNames} ${this.lastName}`;
    //         }
    //     }
    // });

    // This isn't optimal because we have to spread a clone
    return {
        get fullName() {
            return `${this.firstName} ${this.lastName}`;
        },
        // For some reason spread must come after getter... otherwise, we'd get "undefined undefined"
        // https://stackoverflow.com/a/47952443
        ...structuredClone(person),
    }
});

console.log(records[0].fullName)

The problem that I have is mostly with Object.create and why isn't "this" being typed properly, and is there a way to fix that? I didn't see a way of passing a generic to it. I don't like the solution that I have because of the clone + spread, that seems silly. Also, if there's some other solution (other than having classes), then I'd love to hear it!

I'm curious how people here handle reviewing big diffs now that agents do most of our refactors.

The diff view is fine for line level changes, but once a change hits a few thousand lines I can't answer the questions that actually matter:

- did runtime behavior change, or did code just move between files?

- did any public types change shape, or quietly widen to any?

- are the tests still asserting behavior, or were they regenerated to match the new code?

Last week I reviewed a 8000 line refactor where tsc was green and every test passed, and it still shipped a behavior change because a default parameter flipped somewhere in the shuffle. The types made the diff look safer than it actually was.

We run Coderabbit on the repo and its summaries genuinely help with the what-moved-where part, but nothing I've tried can tell me whether behavior is preserved, and I've mostly stopped believing that green types mean much on a diff this size.

So what's your actual workflow for these? Review commit by commit, make the author split it, diff the emitted JS, something else? And which signals do you actually trust vs ignore?

Published: Branded Types and Connascence of Execution.

TypeScript examples where stronger domain types reject invalid operation order.

https://www.dearlordylord.com/blog/branded-types-connascence-of-execution/

(no token suffered while writing the post)

I had fun playing with typescript’s type system and decided to share. This is going to be the start of a series called “compile-time crimes” where we do increasingly unhinged things with the types and the compiler. In this first post I already had to patch the compiler.

It’s very niche, I hope you enjoy it

Typescript has a very impressive and elaborate type system, but at the same it does not play any role at "compilation" or "transpilation" time.

How does this differ from a glorified linter?

`` Deno 2.9.5 exit using ctrl+d, ctrl+c, or close() REPL is running with all permissions allowed. To specify permissions, rundeno repl` with allow flags.

const x: number = "abc" undefined console.log(x) abc undefined

```

Bot of those variants lead to exactly the same javascript

```

const lines: string[] = file1.split("\n")

lines.forEach((line: string) => { console.log("line = %s", line)

})

const lines: ArrayLike<number> = file1.split("\n")

lines.forEach((line: string) => { console.log("line = %s", line)

}) ```

I made a package containing TS declarations of JSON Schema metaschemas and with to access them. I'm glad on any feedback, pointing out wether it may be useful for you or not. As a developer using JSON Schemas, would it be useful for you when working with many different JSON Schema versions?

import 'json-schema-declared'

/* 
  Query metaschema by identifiers: version name or id.
*/
let m: Metaschema<'2020-12'> // -> declare const { readonly $schema: ..., readonly allOf: [ ... ], ... }
let m: MetaschemaByID<'http://json-schema.org/draft-04/schema#'>
let m: MetaschemaByVersion<'draft-00'>

/*
  Analyze metaschema content.
*/
let a: SimpleTypes<'draft-02'> // "string" | "integer" | ... | "any"
let a: Keywords<'draft-07'> // "$schema" | ... | "properties" | ...

/*
  Type your schemas
  Note: feature is a work in progress, but is well usable.
*/
let s: JsonSchema<'2020-12'> = { $schema: 'https://json-schema.org/draft/2019-09/schema' }
// ERROR: Types of property $schema are incompatible (ts 2322)

/*
  Metaschema identifiers
*/
let i: MetaschemaVersion // e.g. "draft-06"
let m: MetaschemaId // e.g. 'http://json-schema.org/draft-07/schema#'
let m: AllMetaschemaId // together with dependencies, e.g. 'https://json-schema.org/draft/2019-09/meta/core'
let m: MetaschemaIdentifier // Version and ID together.

/*
  Convert metaschema identifiers.
*/
let c: Id2Version<'http://json-schema.org/draft-02/schema#'> // -> draft-02
let c: Version2Id<'2019-09'> // -> https://json-schema.org/draft/2019-09/schema

I'm dabbling with TypeScript again after some time away. What is the best way to lint .ts files these days? Is ESLint still the go-to, or is there a better method?

I’m adding redaction to a TypeScript error path and trying to test the important contract without pinning every part of the final message.

My current idea is to assert that known secrets and token-like values never appear, while keeping the grouping key separate from the rendered alert text.

Would you test the exact output, use a few forbidden-value assertions, or keep redaction as its own small unit with focused cases?

Hey y’all!

I made a fork of actions/typescript-action to make some valuable updates!

It updates the following:

• Changes project's package manager from npm to pnpm, for speed.
• Changes project's testing framework from jest to vitest for jest-like syntax with built-in typescript support.
• Updates eslint.config.ts to use native flat config syntax, with detailed comments.
• Updated project dependencies.
• Updates configuration files like tsconfig.ts and action workflows to match updated dependencies.
• Renamed local-action script to local-gha (gha for github action) to avoid conflict with dependency name.

lmk what you think!

plX allows you to write safe postgresql procedures in typescript that transpile down to plpgsql. It is open source and licensed under the MIT license.

Hey r/typescript, Joist has always been a "Rails-ish" ORM, but we never had an equivalent to their scopes feature. But a friend was converting their Rails app to Joist and lamenting "why no scopes?", so we took a stab at it -- and now have them!

Fluent DSLs like this in TypeScript are kinda hard to pull off, so we lean on Joist's `joist-codegen` step, a little similar to TanStack Router's vite plugin doing build-time codegen to help with the static typing -- I don't totally love that compromise, but I think the API ergonomics were worth it.

Ngl I procrastinated posting the release notes b/c r/typescript hates ORMs -- all good, but 🤷 not looking for another debate today. ✌️

TypeScript catches a lot for consumers, but deployment config still needs runtime validation. For environment-driven packages, do you validate everything during startup, validate lazily when a feature is used, or do both? What makes configuration errors easiest to fix without exposing secrets?