# Description
`main` in Pulumi.yaml is supposed to take precedence over `main` in
`package.json`, but we inadvertently broke this in
cf1189bf2c
Fixes https://github.com/pulumi/pulumi/issues/16274
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
Fixes https://github.com/pulumi/pulumi/issues/15733
Historically these packages were direct dependencies of
`@pulumi/pulumi`. To decouple the node SDK from the precise version of
TypeScript, the packages are now declared as optional peer pependencies
of `@pulumi/pulumi` and customers can pick the versions they want.
The reason we mark the peer dependencies as *optional* is to prevent
package managers from automatically installing them. This avoids the
situation where the package manger would install a more recent version
of TypeScript without the user explictly opting in. Newer versions have
stricter type checks, and can thus stop existing programs from running
successfully.
When the peer dependencies are not present, we load the vendored
versions of the modules.
## Checklist
- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
- [ ] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
<!---
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->
# Description
<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a new experimental feature to the NodeJS SDK to register
remote transform functions. These are currently all prefixed 'X' to show
they're experimental.
These transform functions will run even for resources created inside
MLCs.
## Checklist
- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
- [x] I have formatted my code using `gofumpt`
<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
This commit changes how the Node SDK resolves package.json to recursively look up the directory tree for the file when it's not present in the cwd. The previous behavior was to only look in the current directory, and fallback to an empty object when the file could not be found.
This change refactors assignment statements used as expressions
to prefer assignment statements instead. Assignments are often
assumed to now evaluate to a value, but instead to represent a
change to a lexical binding. By using them as expressions, we can
write confusing and buggy code. This commit eliminates those instances,
and enables a lint to prevent future occurances.
The `main` field in package.json is standardized by Node to refer
to a file relative to package.json. The previous commits in this
PR used `main` relative to the Pulumi main directory, which was
incorrect. This commit upgrades two tests, and introduces two more,
to verify the correctness of this behavior and the PR in general.
It appears that a large number of tests were using references
to main fields which don't currently exist. The runtime didn't
produce an error because package.json was being ignored.
This commit adds a test to assert Pulumi programs written as ESM
modules can be executed when their package.json file is located
in the parent directory.
This commit applies the Rome autoformatter to the Node SDK.
These changes are automatically produced. To reproduce these
changes, run `make format` from inside sdk/nodejs.
highlighting. The service doesn't currently support ANSI control
codes so all ANSI control codes are removed before being sent to
the service, but still displayed in the CLI.
10622: Enable ESModule interoperability r=RobbieMcKinstry a=RobbieMcKinstry
<!---
Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation.
-->
# Description
This PR enables ESModule interop for the NodeJS SDK. By enabling interop, we should in theory remove subtle bugs from Pulumi programs that assume our libraries are interopable. In practice, only a few modules weren't already interoperable. Nevertheless, enabling this compiler flag will require future code to be compatible with ESModules, potentially eliminating future bugs.
<!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. -->
Fixes https://github.com/pulumi/pulumi/issues/10621
This PR is required for bundling the NodeJS runtime (https://github.com/pulumi/pulumi/issues/10210).
## Checklist
<!--- Please provide details if the checkbox below is to be left unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my feature works
<!---
User-facing changes require a CHANGELOG entry.
-->
- [x] I have updated the [CHANGELOG-PENDING](https://github.com/pulumi/pulumi/blob/master/CHANGELOG_PENDING.md) file with my change
<!--
If the change(s) in this PR is a modification of an existing call to the Pulumi Service,
then the service should honor older versions of the CLI where this change would not exist.
You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Service API version
<!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. -->
Co-authored-by: Robbie McKinstry <robbie@pulumi.com>
These exported APIs aren't intended for public use. Marking them as `@internal` makes TypeScript remove them from the `.d.ts` files and removes them from our Node.js SDK docs.
previously, when both index.ts and index.js were present
and no main key was provided in Pulumi.yaml, Pulumi would quietly
resolve the entrypoint as index.js. This messages that decision in a warning
* Avoid importing typescript in node SDK where possible
* Lazy-load runtime/closure in dynamic/index.ts
* More targeted runtime import in config.ts
* More precise imports in run-policy-pack/run.ts
* More precise imports for dynamic-provider/index.ts
* More precise imports for automation/server.ts
* Share typescript compiler option loading func in run.ts and run-policy-pack/run.ts
* Lazy-load ts-node that depends on TypeScript
* Break module import cycle
* Fix node lint
* Take required nodejs version into account as specified in engine.node
* Simplify check for strict node engine
* Add changelog entry
* make linter happy
In #7764 and #8655 we added support for ESM entrypoints. However, ESM "default exports" were handled just as "normal" in Node.js dynamic import of ESM - as a `default` proeprty in the export object.
This is not a particularly useful behaviour for Pulumi program entry points, and doesn't quite match some of the special logic we apply to non-object exports in CommonJS modules (invoking exported functions, and then awaiting exports promises).
Instead, this change adds support for default exports, treating the default export (if present) as the full returned export value.
It is for now an error to have both a default export and named exports, since it is unclear what this should mean. In the future, we could potentially relax this and define how these two sets of exports are merged.
This is technically a breaking change from the support added in the recent releases, but only in a narrow case, and in that case the Pulumi stack exports were almost certainly not what the user wanted.
Fixes#8725, which includes a motivating example where this is ~necessary.
This follows up on the changes in #7764 with three additions:
* Support for passing args directly to node so that ESM loaders and other node process level configuration can be accessed via Pulumi
* Support the same default behaviour for loading a ESM module from Pulumi as for node <program>, including support for resolving main entrypoint from package folder.
* Add test cases for .js, pre-complied .ts and ts-node-based `.ts.
This includes test cases that show how to use top-level await in Node.js (which is only possible inside ESM), addressing #5161.
Using ESM via the default ts-node-based TypeScript support is a little tricky, as it is dependent on experimental loader hook support in Node, upon which partially in-progress ts-node support has been added. We cannot make these the default experience yet, but the examples here show how users can configure things themselves to access these features. Once this support solidifies and we can rely on it in all supported Node and TypeScript versions, we may be able to update templates to support more of this by default.
These changes add initial support for the construction of remote
components. For now, this support is limited to the NodeJS SDK;
follow-up changes will implement support for the other SDKs.
Remote components are component resources that are constructed and
managed by plugins rather than by Pulumi programs. In this sense, they
are a bit like cloud resources, and are supported by the same
distribution and plugin loading mechanisms and described by the same
schema system.
The construction of a remote component is initiated by a
`RegisterResourceRequest` with the new `remote` field set to `true`.
When the resource monitor receives such a request, it loads the plugin
that implements the component resource and calls the `Construct`
method added to the resource provider interface as part of these
changes. This method accepts the information necessary to construct the
component and its children: the component's name, type, resource
options, inputs, and input dependencies. It is responsible for
dispatching to the appropriate component factory to create the
component, then returning its URN, resolved output properties, and
output property dependencies. The dependency information is necessary to
support features such as delete-before-replace, which rely on precise
dependency information for custom resources.
These changes also add initial support for more conveniently
implementing resource providers in NodeJS. The interface used to
implement such a provider is similar to the dynamic provider interface
(and may be unified with that interface in the future).
An example of a NodeJS program constructing a remote component resource
also implemented in NodeJS can be found in
`tests/construct_component/nodejs`.
This is the core of #2430.
Also:
- Cleaned up existing tags so they're consistently at the bottom of doc comments where they should be
- Cleaned up some unused imports while I was taking a pass over the files
- Marked one function `@deprecated` that should be deprecated