1d215c2c0c
* Move InstallDependencies to the language plugin This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself. This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this. We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli. An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well. The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC. The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given? * Just warn if pty fails to open * Add tests and return real tty files * Add to CHANGELOG * lint * format * Test strings * Log pty opening for trace debugging * s/Hack/Workaround * Use termios * Tweak terminal test * lint * Fix windows build |
||
|---|---|---|
| .. | ||
| asset | ||
| automation | ||
| cmd | ||
| dist | ||
| dynamic | ||
| iterable | ||
| log | ||
| npm | ||
| proto | ||
| provider | ||
| queryable | ||
| runtime | ||
| tests | ||
| tests_with_mocks | ||
| .eslintrc.js | ||
| .gitignore | ||
| Makefile | ||
| README.md | ||
| config.ts | ||
| errors.ts | ||
| index.ts | ||
| invoke.ts | ||
| metadata.ts | ||
| output.ts | ||
| package.json | ||
| resource.ts | ||
| stackReference.ts | ||
| tsconfig.json | ||
| tslint.json | ||
| utils.ts | ||
| version.ts | ||
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.