Reintroduce type splitting in NodeJS codegen.

[RobbieMcKinstry]

Description

This commit reintroduces the changes that were reverted in #11534. This time, we hide the feature behind language-specific config in the schema, and default it to off.

At this time, providers should not enable the feature until #11560 has been addressed.

Note to reviewers: Observe that this change does not edit the codegen tests. This demonstrates the these changes do not impact the generated code (because the feature introduced here is off by default).

Fixes #11557

Checklist

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

• I have run make changelog and committed the changelog/pending/<file> documenting my change

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

[RobbieMcKinstry]

Marking as draft until CI completes. I expect it to be otherwise ready, but no sense reviewing it before then.

[pulumi-bot]

Changelog

[uncommitted] (2022-12-07)

Bug Fixes

• [sdkgen/nodejs] reintroduce-types-splitting
  #11579

[RobbieMcKinstry]

We know why CI is failing, and I made a PR to fix it. In the meantime, we can go ahead with code review.

[t0yv0]

At this time, providers should not enable the feature until #11560 has been addressed.

Wondering perhaps this feature does not belong on the main branch perhaps until that's addressed? That is don't merge this PR? Or is there a use case where a provider would want to enable it?

[RobbieMcKinstry]

Wondering perhaps this feature does not belong on the main branch perhaps until that's addressed?

We can do that instead. My concern is that when we do eventually merge from the branch back into master, the PR will be massive. That doesn't inconvenience me (I can keep rebasing as needed) but it might be tough for reviewers.

[RobbieMcKinstry]

Converting back into draft for now based on that comment.

[t0yv0]

I've used a stacked PR technique in cases like this but it does still get unwieldy.. The advantage of keeping things out is that when you are debugging a prod issue you are not looking at code that's not in use. Really depends on how the team decides to handle these situations 🙏

[RobbieMcKinstry]

Yeah, that makes a lot of sense. I'll go with a stacking PRs approach and give that a try.