chore: update decorators in @packages/data-context to use Stage 3 decorators

[AtofStryker]

What would you like?

Currently, the @packages/data-context package uses the TypeScript experimentalDecorators option, which uses the Stage 2 decorators proposal. Since TypeScript 5 released, the default is now to using the official Stage3 / accepted decorators proposal, which takes 2 arguments instead of 3 arguments. This can be seen with the cached decorator.

Why is this needed?

We are planning to replace ts-node with tsx to transpile user config files as well as run certain cypress packages. tsx. When performing the POC described in #30426, we ran into a few issues, this one in particular when running the binary smoke tests:

Error [ERR_INTERNAL_ASSERTION]: Code: ERR_MODULE_NOT_FOUND; The provided arguments length (2) does not match the required ones (3).
This is caused by either a bug in Node.js or incorrect usage of Node.js internals.
Please open an issue with this stack trace at https://github.com/nodejs/node/issues

This is most likely an issue with the data-context package, which doesn't compile itself and is instead references as raw typescript inside @packages/server, @packages/graphql to manage state while cypress is running, and is also used in @packages/app, @packages/launchpad, and @packages/frontend-shared for cy-in-cy tests to mutate server state for us to be able to test cy-in-cy correctly. We HAVE seen this issue inside our system tests, and have to offer a test specific tsconfig.json to work around the issue (which can be seen here).

Since the tsconfig.jsons per package do NOT compile the data-context package directly, the package is left configless in tsx, in which tsx then tries to compile the file, which fails because we are using experimentalDecorators in the data-context package. experimentalDecorators uses the ECMA stage 2 proposal of the decorators (which was introduced pre typescript 5), which takes 3 arguments. TypeScript 5 added support for the TC39 Stage 3 decorators, which only takes 2 arguments. I believe this is why we are seeing this issue.

We would likely get better output when we update Electron 35 as it is on Node 22 (see nodejs/node#51477).

Other

you can reproduce the node error on the smoke test by running the following locally:

yarn binary-build
V8_SNAPSHOT_DISABLE_MINIFY=1 yarn binary-package --skipSigning
yarn binary-smoke-test