# Ts.ED's default branch is called production

> Ts.ED is a TypeScript framework over Express built on decorators, dependency injection and a schema layer that generates both JSON Schema and OpenAPI. It is also, structurally, a very busy repository: the branch you land on by default is named production, the release history moved three times in a day, five assistant configuration directories are committed side by side, and the postinstall script installs a second package tree and then calls out to a forge API.

**tsedio/tsed** —  :triangular_ruler:  Ts.ED is a Node.js and TypeScript framework on top of Express to write your application with TypeScript (or ES6). It provides a lot of decorators and guideline to make your code more readable and less error-prone. ⭐️ Star to support our work! 

- Repository: https://github.com/tsedio/tsed
- Website: https://tsed.dev
- Stars: 3,087 · Forks: 292
- Language: TypeScript
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/tsedio-tsed

## The branch you land on is the one named production

The default branch for this repository is called production.

That is not the name a tooling default expects, and it is not the name a reader expects. Clone scripts, continuous integration defaults, link resolvers and release automation that hardcode a branch name all need to be told, and anyone who assumes the conventional name will either find nothing or, worse, create a second branch beside it.

The release history explains why that name is plausible. There are three releases from the last two days, and two of them are twenty-four minutes apart on the same day, with the newest tagged in the same minute as the last commit to the branch. So this is a project shipping continuously from a branch whose name says it is where production-ready code lives.

Whether that is a deliberate policy or a naming leftover, the practical effect is the same: the thing you check out by default is whatever the maintainers consider shippable, and there is no second branch here acting as a staging area.

Everything else in the repository is conventional enough that this one detail is the thing you will trip over first.

## The copyright line stops three years before the last release

The licence section names the MIT licence and then gives a copyright line with a single author and a year range that ends in 2023.

The newest release is dated October 2026. So the copyright range has not been touched in three years while releases have continued weekly, and the licence text quoted below that line is cut off partway through its own standard wording.

For MIT this is cosmetically wrong rather than legally broken. There is no obligation to update a year range, and the grant in the licence text is what governs. But it is the last thing in the readme, it is the first thing an auditor reads, and a three-year-stale range on an actively released project invites exactly the question you would rather answer in advance.

The rest of the funding information is more complicated rather than less. There are two separate systems: a backer programme on one funding platform and a sponsor programme on the forge, with two badge links at the top of the file and two separate sections at the bottom, each asking for support and each promising a logo or a link.

None of that is unusual for a project that has been going a long time. It is a small sign of the same thing the branch name is: the metadata around the code has not been revisited in a while.

## The install hook installs a second package tree and calls an API

The root manifest is private, because it is the monorepo root rather than a published package, and it has a postinstall hook.

The hook changes into the documentation directory, runs the package manager there to install that site's own dependencies, changes back, and then runs a script from a tools directory whose name says what it does: it fetches the project's sponsors.

So installing this repository does two things nobody expects from installing a framework. It sets up a second dependency tree for a website, and it makes a network call to a forge API, presumably authenticated, and writes the result somewhere in the tree.

For a developer cloning and building locally, that is a slow and fragile first step: it needs network access to two places, and it needs whatever token the sponsors tool expects. For anyone depending on a published package, none of this applies, because the hook belongs to the private root manifest and is not what consumers install.

That distinction is the reason to read it, and it is exactly the distinction the readme never draws.

## Eleven workspace globs, five release tools, five assistant directories

Count what is coordinating this repository and the number is uncomfortable in a good way.

Workspaces: eleven globs. One covers the top level of the packages directory and ten more cover subdirectories inside it, by concern: configuration, GraphQL, object mapping, utilities, platform adapters, security, specs, test containers, third parties, and a separate tools directory.

Release tooling: five systems. A monorepo orchestration file, a semantic release configuration, a bespoke command line tool in the tools directory that the root scripts call for configuration and cleaning, a commit message linter configuration, and a formatter plus linter pair configured in two files at the root, alongside a Prettier badge.

Type checking: three configuration files, one general, one for tooling, one for specs.

Documentation generation: its own configuration file, plus a documentation directory with its own package tree.

And five directories for assistant configuration, side by side, for five different assistants, plus a general agent instructions file and a lock file for agent skills.

Each of those is defensible on its own. Together they mean the cost of contributing here is learning five release tools and knowing which assistant configuration a change is expected to touch.

## The example imports three middlewares and names them as strings

The server example is fifteen lines and it is the best thing in the readme, because it shows the whole shape of the framework in one decorator.

```typescript
@Configuration({
  port: 3000,
  middlewares: ["cookie-parser", "compression", "method-override", "json-parser", "urlencoded-parser"]
})
export class Server {}
```

The class is empty. Everything is in the decorator, and the middleware list is five strings by package name.

Now look at the imports above that block. Three packages are imported by name: a cookie parser, a compression helper and a method override. None of them appears in the decorator, and none of them is referenced anywhere else in the example.

So the imports are leftovers from an earlier version of the sample that wired middleware as objects. They are harmless, and they are the kind of thing a reader copies, because copying the example means carrying three unused imports into a project where a linter will complain about them.

The bootstrapping half of the example is more interesting. To run, you do not instantiate a server; you ask a platform adapter to bootstrap your configuration class, then listen. The choice of Express is made at the call site rather than in the configuration, which is how the same application class runs on more than one platform.

## A repository stats heading with nothing under it

Near the bottom of the readme there are two headings with nothing in them.

One is for repository statistics. The other is a contributors section that links to the forge's contributors graph rather than listing anything.

Both are the kind of thing that survives because nobody removes a heading. They also make the file look more finished than it is: a reader scrolling the page sees a statistics section and assumes the numbers are below the fold, and a reader looking for how many people work on this has to click a link to find out.

The code example above them has the same problem from the other direction. The controller example is cut off mid-decorator, in the middle of a method signature, so the one example that shows how routing actually works ends before it shows anything.

None of this is a criticism of the project, which has an extensive documentation site and a tutorials section and a Slack. It is a note about the readme specifically: the three things a reader most wants from it, a complete controller, a project size, and a contributor list, are the three it leaves empty or unfinished.

## Conclusion

Ts.ED fits a team that wants decorators and a schema-first API surface in a Node service, and that would rather have one dependency injection container than wire it themselves. Two things to check before you take the dependency. Read what its install hook does, because it installs a second package tree for the documentation site and then runs a tool that queries the forge for sponsor data, which is not what anyone expects from installing a framework. And check the branch you are on, because the default is not the conventional name and the release tags come from a pipeline configured separately from the version in the root manifest.

## FAQ

### How much is Costco studio shed?

That question is about a prefabricated building and nothing to do with this repository. Ts.ED here is a TypeScript framework over Express that builds server applications with decorators, dependency injection, and a schema layer producing JSON Schema and OpenAPI for controllers, models and services.

### Can I legally sleep in a shed?

A question about building regulations rather than software. Nothing in this repository addresses it. The framework's own scope is server-side applications: it supports Express and Koa as platforms, the Node and Bun runtimes, a command line generator, and serverless deployments.

### What system does this framework use?

It is built on Express, and the readme also lists Koa as an alternative platform, along with a command line tool for project generation and serverless targets. An application is configured by decorating an empty class, and the platform adapter is chosen when the application is bootstrapped rather than in the configuration itself.

### Does tsed need a database?

Not by itself. The readme lists integrations rather than requirements: two object mapping layers, a MongoDB one, GraphQL, socket support, a generated interface layer, and Passport. What the framework requires at the core is the schema layer, which is where the JSON Schema and OpenAPI output comes from.

### What is the tsed license?

The MIT licence, with a single named author and a copyright year range that ends in 2023. The root manifest also declares MIT and is private, since it is the monorepo root rather than a published package.

## Sources

- [License: MIT](https://github.com/tsedio/tsed/blob/production/LICENSE)
- [Project website](https://tsed.dev)
- [README](https://github.com/tsedio/tsed/blob/production/README.md)
- [Releases](https://github.com/tsedio/tsed/releases)
- [tsedio/tsed on GitHub](https://github.com/tsedio/tsed)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tsedio-tsed