Update typescript cre-sdk: improve TS experience when dealing with NodeJS APIs

[ernest-nowacki]

This PR updates cre-cli generate templates with @chainlink/cre-sdk version of 1.2.0 which includes improved DX experience when working with TS workflows and using unsupported APIs.

Context

Users are often thrown off guard and are presented with unreadable WASM traces when they use some of the NodeJS APIs that are not available in our Javy/QuickJS env. We would now change it to more readabile errors like this one:

That's a new compile-time check looking for imports of APIs like node:crypto, node:http etc.

We're also making changes to default tsconfig.json to NOT INCLUDE by default NodeJS types. What is being picked up however is our own custom types, marking APIs as never and deprecated. What it does in practice?

When you hover over imports in your IDE you would see suggestion to use our capabilities:

If you still decide to use particular API in the code itself you would see it crossed out:

If you run your bun typecheck you would also see TS errors:

It should give you a decent understanding of what's wrong compared to current experience.

How to test

New workflows

1. This PR exposes extra command bun typecheck to verify types in your workflow.
2. Simulating will now look for restricted imports from node and error out - rather than showing wasm errors.

For pre-existing workflows:

1. Update your workflow package.json to point to cre-sdk@1.2.0.
2. Add types: [] in compilerOptions in your workflow tsconfig.json.
3. bun install.
4. Simulate.

Required

• SDK release tag for testing: https://github.com/smartcontractkit/cre-sdk-typescript/releases/tag/v1.2.0

Next steps

This is just first step towards better use of TS for checking workflows. Next steps planned:

• bake typechecks into simulate / cli itself
  • current PR gives you optional bun typecheck we will make it required for the simulate / deploy tasks (with an escape hatch baked in --ignoreTypeChecks or similar)
• extend our import health checker to go into 3rd party libraries
  • for example if you import crypto-sha256 which under the hood uses restricted API we would like to catch that too
• make TS error out as soon as import happens
  • currently actual blocking TS error happens when you try to use unsupported module (for example: crypto.randomBytes(16)), it would be better if we could error out as soon as import { crypto } from 'node:crypto'
• add extra linter with non-blocking warnings that catches uses of Promise.all and similar - available but discouraged.