This message was deleted.

hey Chris, is there a specific TS feature that's causing an issue for you with the version of ts-node we ship? updating ts-node has a number of implications for us. the upstream project removed caching, causing a large performance regression for our users, and we need to make sure that update doesn't break any users as well. making ts-node a peer dependency would be a major version bump for Pulumi for example, because it would break all of our existing users' TypeScript stacks. knowing exactly what isn't working and why you need to transpile/bundle your Pulumi project with another tool before running

pulumi up

will help build the case for us to update and/or invest in solving those performance issues

Appreciate the position and think it's good that the focus is on performance. Given we can pre-compile ourselves and just provide JS there should not really be any issue but it seems the dynamic runtime & serialisation is presuming Typescript even though I am providing JS? It's a tricky one to be specific about to be honest. It's an entire major version of the programming language we are developing our apps in (ie. Typescript 3 -> 4). We have a large monorepo and maintain consistency of the typescript version we use so that people can easily jump between projects without any "gotchas" of version differences. If I recall correctly the major issue when trying to just pass our TS was something around module interoperability configuration in tsc. I will see if I can find time to quickly switch and try it out again and get some output.

The way closures are serialized involves some tricky business with functions and computing the set of packages required to be in the lambdas package.json/node_modules. I don't think we test that it'll work when the user has used a bundler to bundle everything into a single JS file, and I'm not sure what it would mean for that either. My advice, and I've done this before, is not to bundle but to compile to a dist directory of transpiled .js files.