4e90fcb781
This commit implements `CreateIfNotExists`, a new resource option that allows programs to specify resource options that should be created only if they do not already exist in the provider. Use cases for this feature include "global" or shared resources, such as AWS service-linked providers within an account, or SSL policies within a GCP account/project. `CreateIfNotExists` behaves as follows: * The option accepts an ID, much like `Import`, that will be used to determine whether or not a resource exists using a `Read` operation. If it does, resource inputs must match as they would be required to in an ordinary import. If not, the resource is created as usual. * Due to the semantics specified above, it is an error to specify both `CreateIfNotExists` and `Import` resource options on a single resource. The "if not exists" part is handled by a provider `Read` call that we make in step generation. This is not ideal, since we'd like step generation to be non-blocking (and `Read` could block for an arbitrary amount of time). However, there aren't many other good options for achieving this: * Source evaluation would be a good middle ground, but this would require changing the contract of `Read`/introducing another call since we do not have a URN at this point. * Parallelising step generation (see e.g. #15026). This is the "best" outcome and feels the most correct, but carries a large amount of risk. There _are_ instances of us breaking this rule (not blocking in step generation) already (e.g. `Check` and `Diff`, which "should" be fast but in reality could do anything they like), and the hypothesis is that there won't be many resources with this option in a given stack, so this feels like an acceptable compromise. A set of lifecycle tests capturing `CreateIfNotExists`' interactions with existing resource options and scenarios are included. This commit does not include SDK updates to use the new option; these will be introduced in future changesets. Part of #16189 |
||
|---|---|---|
| .. | ||
| asset | ||
| automation | ||
| cmd | ||
| dist | ||
| dynamic | ||
| iterable | ||
| log | ||
| npm | ||
| proto | ||
| provider | ||
| queryable | ||
| runtime | ||
| tests | ||
| tests_with_mocks | ||
| types | ||
| vendor | ||
| .eslintrc.js | ||
| .gitignore | ||
| Makefile | ||
| README.md | ||
| biome.json | ||
| config.ts | ||
| errors.ts | ||
| index.ts | ||
| invoke.ts | ||
| metadata.ts | ||
| output.ts | ||
| package.json | ||
| resource.ts | ||
| stackReference.ts | ||
| tsconfig.json | ||
| tsutils.ts | ||
| typescript-shim.ts | ||
| utils.ts | ||
| version.ts | ||
| yarn.lock | ||
README.md
Pulumi Node.js SDK
The Pulumi Node.js SDK lets you write cloud programs in JavaScript.
Installation
Using npm:
$ npm install --save @pulumi/pulumi
Using yarn:
$ yarn add @pulumi/pulumi
This SDK is meant for use with the Pulumi CLI. Visit Pulumi's Download & Install to install the CLI.
Building and Testing
For anybody who wants to build from source, here is how you do it.
Prerequisites
This SDK uses Node.js and we support any of the Current, Active and Maintenance LTS versions. We support both NPM and Yarn for package management.
At the moment, we only support building on macOS and Linux, where standard GNU tools like make are available.
Make Targets
To build the SDK, simply run make from the root directory (where this README lives, at sdk/nodejs/ from the repo's
root). This will build the code, run tests, and install the package and its supporting artifacts.
At the moment, for local development, we install everything into $HOME/.dev-pulumi. You will want this on your $PATH.
The tests will verify that everything works, but feel free to try running pulumi preview and/or pulumi up from
the examples/minimal/ directory. Remember to run tsc first, since pulumi expects JavaScript, not TypeScript.