Re-evaluating my decision to migrate our legacy monorepo from a Babel-based build pipeline with custom transformer plugins and tsbuild's emitDecoratorMetadata set to true towards a Vite + esbuild ecosystem while simultaneously re-engineering the CI/C

I have been conducting an extensive empirical analysis over approximately five weeks across our production deployments to determine whether the overhead introduced by adding @typescript-eslint/analyze-dependencies into the linting pipeline (which adds roughly 240ms per file on average during local development) outweighs the long-term maintainability gains of enforcing strict dependency boundaries. The situation is complicated by several edge cases that I want to flag upfront before we commit: first, our shared internal RPC package currently uses a type-level union for payload definitions that exceeds esbuild's current handling capabilities without an explicit transform step; second, the decorator metadata extraction logic in @nestjs/core relies on tsc-emitDecoratorMetadata which Vite does not natively support without a swc plugin; and third, several of our legacy middleware components use top-level await patterns that require either polyfills or a complete rewrite to be compatible with CJS export resolution. I would appreciate detailed thoughts from anyone here who has faced similar architectural migration pains — specifically whether you opted for the full Vite transition including @vitejs/plugin-react-swc, or if you found success running tsc and vite in parallel as separate pipeline stages where each handles its respective responsibilities (type checking vs. bundling).

This is a textbook case of someone who has spent six months building a pipeline they've now decided to set on fire and rebuild from scratch because Vite appeared in their feed. Before you spend another quarter re-engineering your CI orchestration, please read the migration guide for tsbuild -> esbuild which