Avoid importing typescript unless necessary

[t0yv0]

Description

The key motivation for this change is speeding up startup of small JavaScript programs. That is:

pulumi new javascript

# edit Pulumi.yaml to have:
# runtime:
#  name: nodejs
#  options:
#    typescript: false

time pulumi preview
# before : 1.9s
# after: 1.6s
# 300ms gained or 15%

This 300ms is simply is the cost of adding ts-node and typescript dependency to the imports.

Importing "runtime" directly considered harmful because it imports "typescript" indirectly via "closure" support.

Fixes # (issue)

Checklist

• I have added tests that prove my fix is effective or that my feature works

• I have updated the CHANGELOG-PENDING file with my change

• Yes, there are changes in this PR that warrants bumping the Pulumi Service API version

[t0yv0]

@RobbieMcKinstry brings up a question whether lazy-load technique taken from https://www.typescriptlang.org/docs/handbook/modules.html#optional-module-loading-and-other-advanced-loading-scenarios will be supported in all the needed module environments (CommonJS etc).

[t0yv0]

Adding platform-team reviewers to seek out node expertise. Also hoping tests might help catch.

[RobbieMcKinstry]

After reviewing https://blog.bitsrc.io/javascript-require-vs-import-47827a361b77 I feel like its likely.

[t0yv0]

Let me work through failing tests first.

[Frassle]

Importing "runtime" directly considered harmful because it imports "typescript" indirectly via "closure" support.

My current intention is to remove closure in 4.0 and ship it as a separate package.

[t0yv0]

That'd be good but the changes here still help since ts-node imports depend on typescript. I think I'd like to ship this. Concerns I've heard so far was:

• does it work with all JS module systems (which ones does Pulumi support, how do I test)
• does it slow down TypeScript projects (will tests)

[RobbieMcKinstry]

@t0yv0 After digging into minification, I don't think it will slow down typescript builds, since we don't bundle. If we bundled, then a dynamic import would cause a disk read that otherwise wouldn't have occurred in the static import scenario.

[t0yv0]

Ah so would bundling embed "typescript" and "ts-node" JavaScript code inside the "pulumi" bundle? I thought it's just a matter of whether pulumi specific modules are distributed in one or several files.

With that being clarified it seems good for us not to bundle "typescript" since it is large and is not always used by the Pulumi code, it's optional in some scenarios.

[AaronFriel]

This looks good to me - I don't think a delayed require() will be a problem.

[RobbieMcKinstry]

Ah so would bundling embed "typescript" and "ts-node" JavaScript code inside the "pulumi" bundle? I thought it's just a matter of whether pulumi specific modules are distributed in one or several files.

With that being clarified it seems good for us not to bundle "typescript" since it is large and is not always used by the Pulumi code, it's optional in some scenarios.

Yes, if the runtime doesn't use any dynamic imports, then adding bundling would (by default) bundle typescript and ts-node. Which I agree is something we'd like to avoid.