our rule is no parent relative imports outside the current folder. same folder stays ./x, anything else goes through @/ so it doesnt matter how deep the file moves later.

works fine but i know its not the only way people solve this. monorepo package boundaries, tsconfig paths, eslint rules banning the pattern outright, curious what you landed on and whether it survived contact with a big refactor

what broke first when your team tried to enforce this

Hey r/typescript! I've shared progress updates on numpy-ts throughout the year, and it's continuing to mature into a production-ready lib.

With some continued WASM SIMD optimization and megamorphic loop hunting, numpy-ts is now 1.36x faster than native NumPy (geomean) across 10,500 benchmark specs, spanning all dtypes and functions. You can learn more about the benchmark methodology here.

If you get a chance to try it out, lmk what you think!

This was written by a human; numpy-ts was written with some AI assistance. Read my AI disclosure for more info.

I wanted a simple way to catch common issues that can easily be missed before pushing a project to production.

RepoDrift currently checks:

• Potential exposed credentials and secrets
• Dependencies and lockfiles
• Large and suspicious files
• Git status
• Basic code metrics
• Repository health

It runs locally and doesn't require uploading your source code for the current analysis.

You can install it with:

npm install -g u/repodrift/cli

Then:

repodrift scan

It's still an early project. I'm focusing on making the core analysis useful and reliable before adding AI-based explanations.

I'd like to hear from web developers: what checks would you want a tool like this to perform before deployment?

GitHub: https://github.com/GokulKir/repodrift

NPM: https://www.npmjs.com/package/@repodrift/cli

My project is a Playwright automation framework. I keep getting mixed answers on what they should be so I'm wondering if someone can enlighten me on what values are recommended.

Hey r/typescript,

I've been working on Oasis Editor, an open-source document editor built in TypeScript with its own Canvas-based rendering engine.

Instead of relying entirely on contenteditable and DOM layout, the editor has its own pipeline for paged layout, text rendering, selections, images, tables, and document geometry.

The public API is strongly typed and built around commands and plugins, with vanilla JS, React and Vue integrations plus a headless runtime.

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback from TypeScript developers, especially around the public API and architecture.

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.

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!

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!

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?