This commit improves the TypeScript TypeDocs for the remaining modules
in the NodeJS SDK. Specifically:
* It adds documentation to interfaces, properties, etc. that are missing
it.
* It transforms would-be TypeDoc comments erroneously written using
either `/*` (a single asterisk) or `//` (a normal line comment) to
actual TypeDoc comments.
* It standardises on TypeDoc's `{@link Name}` syntax for linking
identifiers, as opposed to the mixture of backticks and square brackets
we have today.
* It fixes typos and generally cleans up the formatting here and there,
as well as introducing more consistency where the same concepts crop up
in multiple places.
---------
Co-authored-by: Thomas Gummerer <t.gummerer@gmail.com>
* 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
* Enable unit testing for Pulumi programs
This change enables rudimentary unit testing of your Pulumi programs, by introducing a `PULUMI_TEST_MODE` envvar that, when set, allows programs to run without a CLI. That includes
* Just being able to import your Pulumi modules, and test ordinary functions -- which otherwise would have often accidentally triggered the "Not Running in a CLI" error message
* Being able to verify a subset of resource properties and shapes, with the caveat that outputs are not included, due to the fact that this is a perpetual "dry run" without any engine operations occurring
In principle, this also means you can attach a debugger and step through your code.
* Finish the unit testing features
This change
1) Incorporates CR feedback, namely requiring that test mode be
explicitly enabled for any of this to work.
2) Implements Python support for the same capabilities.
3) Includes tests for both JavaScript and Python SDKs.
* Add a note on unit testing to the CHANGELOG
* Use Node 8 friendly assert API
* Embellish the CHANGELOG entry a bit
Prior to this change, if you ended up with multiple Pulumi SDK
packages loaded side-by-side, we would fail in obscure ways. The
reason for this was that we initialize and store important state
in static variables. In the case that you load the same library
twice, however, you end up with separate copies of said statics,
which means we would be missing engine RPC addresses and so on.
This change adds the ability to recover from this situation by
mirroring the initialized state in process-wide environment
variables. By doing this, we can safely recover simply by reading
them back when we detect that they are missing. I think we can
eventually go even further here, and eliminate the entry point
launcher shim altogether by simply having the engine launch the
Node program with the right environment variables. This would
be a nice simplification to the system (fewer moving pieces).
There is still a risk that the separate copy is incompatible.
Presumably the reason for loading multiple copies is that the
NPM/Yarn version solver couldn't resolve to a shared version.
This may yield obscure failure modes should RPC interfaces change.
Figuring out what to do here is part of pulumi/pulumi#957.
This fixespulumi/pulumi#777 and pulumi/pulumi#1017.
This change adds back component output properties. Doing so
requires splitting the RPC interface for creating resources in
half, with an initial RegisterResource which contains all of the
input properties, and a final CompleteResource which optionally
contains any output properties synthesized by the component.
This change adds functions, `pulumi.getProject()` and `pulumi.getStack()`,
to fetch the names of the project and stack, respectively. These can be
handy in generating names, specializing areas of the code, etc.
This fixespulumi/pulumi#429.