Your decorator library silently breaks on Vite. Here's why (and a fix) — ts-jackson 2.0

Ilias Gazdaliev — Tue, 28 Jul 2026 10:12:46 +0000

You have a class that maps an API response. It works perfectly in your old webpack + ts-loader project:

@Serializable()
class Event {
  @JsonProperty()
  startsAt: Date

  @JsonProperty()
  attendees: number
}

You move to Vite. It compiles. It runs. No warnings. And then, somewhere far from this file, production throws event.startsAt.getTime is not a function — because startsAt is quietly a plain string now, and attendees might be one too.

Nothing crashed at the mapping site. That's what makes this failure mode nasty. Here's what's actually going on.

Why: the two-flag magic trick

Every classic decorator-metadata library — class-transformer, TypeORM, typescript-json-serializer, ts-jackson 1.x — relies on two tsconfig flags:

{
  "experimentalDecorators": true,
  "emitDecoratorMetadata": true
}

The first enables the legacy decorator syntax. The second is the magic one: it makes the TypeScript compiler look at your type annotation (startsAt: Date) and secretly emit a runtime value next to the decorator:

// what tsc actually generates (simplified)
Reflect.metadata('design:type', Date)

That's how @JsonProperty() with zero configuration knows it should build a Date. The type annotation — normally erased at compile time — gets smuggled into the runtime.

Here's the catch: emitting design:type requires actually resolving types. Is startsAt's annotation a class? An interface? An import alias? Answering that means type-checking the program.

Now recall why esbuild is fast: it transpiles file-by-file and never type-checks. It just strips annotations. So esbuild doesn't implement emitDecoratorMetadata — not as an oversight, but because implementing it would require becoming the thing it was built to replace. And Vite transforms your TypeScript with esbuild.

The result on a stock Vite project:

Reflect.getMetadata('design:type', target, 'startsAt') // undefined

The decorator still runs. Metadata is just… missing. Your mapping library falls back to "no type known", passes the raw JSON value through, and you get a string where a Date should be. No error at the site of the lie — only downstream, at runtime, in whatever code first trusts the type.

(SWC, for the record, can emit decorator metadata, but it's opt-in config — stock setups frequently miss it too.)

The fix: decorators that don't need a compiler accomplice

Since 5.0 — with decorator metadata following in 5.2, TypeScript's default decorator mode — no flags at all — implements the TC39 standard decorators proposal, together with the decorator-metadata proposal (Symbol.metadata). Standard decorators are pure runtime semantics: the decorator receives a context object, stores whatever metadata it wants, and no compiler magic is involved anywhere.

Which means they work under esbuild. And Vite. And every bundler that can handle modern JavaScript — because there's nothing to implement beyond the syntax itself.

There's one honest trade-off: the standard has no equivalent of design:type, by design — JavaScript has no types at runtime, and TC39 doesn't standardize compiler tricks. So type inference from annotations is gone; where conversion matters, you declare the type explicitly.

ts-jackson 2.0: both worlds, auto-detected

I just shipped ts-jackson 2.0, and the headline feature is exactly this: it supports both decorator modes, and detects at runtime which one invoked it. Same imports, same API.

Legacy mode (tsc, flags on) — full type inference, exactly like v1:

@Serializable()
class Event {
  @JsonProperty()
  startsAt: Date            // inferred from the annotation
}

Standard mode (Vite, esbuild, no flags) — explicit types:

@Serializable()
class Event {
  @JsonProperty({ type: Date })
  startsAt: Date

  @JsonProperty({ elementType: Image })  // elementType implies an array
  images: Image[]
}

If you're not familiar with ts-jackson from the original post

Introducing ts-jackson, a typescript library to deserialize/serialize deeply nested json structures.

Ilias Gazdaliev — Tue, 10 May 2022 18:40:10 +0000

ts-jackson is a json seralization library aimed to effortlessly handle serialization/deserialization of deeply nested json structures.

For example:

const jsonData = {
  images: {
    items: [
      {
        height: 300,
        url:
          'https://i.scdn.co/image/ab67616d0000b27380368f0aa8f90c51674f9dd2',
        width: 300,
      },
      {
        height: 640,
        url:
          'https://i.scdn.co/image/ab67616d00001e0280368f0aa8f90c51674f9dd2',
        width: 640,
      },
    ],
  },
}

@Serializable()
class Playlist {
  @JsonProperty('images.items[1]')
  readonly backgroundImage: Image
}

const deserialized = deserialize(jsonData, Playlist)
// Playlist {
//   backgroundImage: Image {
//     height: 640,
//     width: 640,
//     url: 'https://i.scdn.co/image/ab67616d00001e0280368f0aa8f90c51674f9dd2'
//   }
// }
const serialized = serialize(deserialized)
// {
//   images: {
//     items: [undefined, {
//       height: 640,
//       width: 640,
//       url: 'https://i.scdn.co/image/ab67616d00001e0280368f0aa8f90c51674f9dd2',
//     }],
//   },
// }

It uses Lodash _.get/_.set to resolve property paths and supports every pattern provided by Lodash.

You can check out the full api here:
https://github.com/Eljoy/ts-jackson

Every feedback is truly welcomed. :)

DEV Community: Ilias Gazdaliev

Your decorator library silently breaks on Vite. Here's why (and a fix) — ts-jackson 2.0

Why: the two-flag magic trick

The fix: decorators that don't need a compiler accomplice

ts-jackson 2.0: both worlds, auto-detected

Introducing ts-jackson, a typescript library to deserialize/serialize deeply nested json structures.