Commit Graph

89 Commits

Author SHA1 Message Date
Will Jones 100470d2e7
Revert "Implement `dependsOn` for invokes in the NodeJS SDK ()" ()
From SDKs, we call invokes in one of two ways:

* In a "non-output" context (e.g. `getX`), which has a result dependent
on the language (e.g. a `Promise` in NodeJS) that _does not_ track
dependencies.
* In an "output" context (e.g. `getXOutput`), which has an `Output` type
and does track dependencies.

In the non-output case, `dependsOn` really doesn't make sense, since
this style of invoke is inherently ignoring dependency tracking/outputs.
This commit thus reverts 492c57c7dd so
that we can rethink the design before people's programs are subtly
broken in this case.
2024-07-12 10:16:55 +00:00
Will Jones 492c57c7dd
Implement `dependsOn` for invokes in the NodeJS SDK ()
This commit adds support for passing `dependsOn` to invokes (whether
streamed or not) in the NodeJS SDK. This allows programs to ensure that
certain invokes are executed after things they depend on, even if that
dependency is not implicitly captured with an input-output relationship.

Part of 
2024-07-03 14:47:59 +00:00
Will Jones d64448ec3b
Replace Rome with Biome in the NodeJS SDK ()
As @denbezrukov notes in , Rome (https://github.com/rome/tools,
the JavaScript toolchain we have been using to format and lint code in
the NodeJS SDK) has been deprecated. Biome (https://biomejs.dev/) has
sprung up in its place as a community fork and appears to be the best
bet for migration going forward. This commit introduces Biome, ports the
bits of configuration that need changing and updates formatting
accordingly.

Closes 

Co-authored-by: Denis Bezrukov <6227442+denbezrukov@users.noreply.github.com>
2024-06-24 11:14:56 +00:00
Julien P fa2a196c27
Vendor TypeScript and ts-node ()
<!--- 
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. -->
2024-04-10 15:26:37 +00:00
Julien P dd1d8607ae
Make function serialization work on typescript 4 and 5 ()
# Description

Builds on top of https://github.com/pulumi/pulumi/pull/15753

Fixes https://github.com/pulumi/pulumi/issues/15735

There are a couple breaking changes in the typescript API that we use in
`sdk/nodejs/runtime/closure/rewriteSuper.ts`. This PR adds a shim that
is used to bridge the differences and versions the snapshots where
needed.

This does not make typescript a peer dependency yet. Instead the tests
force a specific version to be used via [yarn
resolutions](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/).

## 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. -->
2024-03-27 10:03:57 +00:00
Julien P f6cbf82d59
Move mockpackage tests to closure integration tests ()
# Description

The tests using `mockpackage` really should be integration tests. We
worked around this by including `mockpackage` in our dependencies, but
this has required some hackery in the build step to remove it again
there.

Now that we have the closure tests setup as integration tests, we can
add the tests using mockpackage there.

## 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. -->
2024-03-26 11:38:01 +00:00
Julien P e3d0decccc
Reorganize closure tests to prepare for multiple typescript versions ()
# Description

In preparation of https://github.com/pulumi/pulumi/issues/15735 we make
the closure tests proper integration tests so that we can run them with
different typescript versions. Move each test to its own folder instead
of one large file.

This PR only changes tests, and does not touch any of the function
serialisation code.

Some snapshots had to be updated for indentation changes.

Hidden after all the test cases is the test script
[sdk/nodejs/tests/runtime/testdata/closure-tests/test.ts](dfcc953c08/sdk/nodejs/tests/runtime/testdata/closure-tests/test.ts)

Verified that tests run in CI
https://github.com/pulumi/pulumi/actions/runs/8389170587/job/22975068167?pr=15753

## 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. -->
2024-03-25 13:19:17 +00:00
Julien P 5a19d754d7
Fix codepaths computation when working dir is nested relative to package.json ()
# Description

When using `tsc` to precompile typescript in a monorepo, we need to work
relative to the location of `package.json`, not where the pulumi program
lives (which is usually nested further down).

## 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. -->
- [ ] 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. -->
2024-03-08 16:16:47 +00:00
Julien P be0fe6b1a6
Replace deprecated read-package-tree with @npmcli/arborist ()
<!--- 
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.
-->

read-package-tree is deprecated. Additionally it has a dependency that
is flagged by security scanners.

<!--- 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/9129

Ref https://github.com/pulumi/pulumi/issues/12688

## 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. -->
- [ ] 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. -->
2024-02-26 18:40:28 +00:00
Julien P 0d3d279bdc
Detect npm and yarn workspaces setups ()
# Description

Make `pulumi install` detect npm and yarn workspaces setups and
successfully install dependencies.

Fixes  

## 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`
2024-02-16 08:25:12 +00:00
Abhinav Gupta a455e0005f
sdk/node/StackReference: Add getOutputDetails
NodeJS equivalent of the StackReference.GetOutputDetails
method and accompanying type added to the Go SDK in .

This will allow users of the TypeScript and JavaScript SDKs
to fetch outputs from stack references directly--without going through
an Output type.

Couple notes about testing:

- `MockMonitor.readResource` kept exploding because the getCustom method
  was missing on the provided object.
  I didn't find any examples in the Node SDK
  of using mocks to test StackReferences,
  so I'm guessing this was an unexercised code path.
  I've fixed that.
- It seems that the JavaScript SDK promotes an entire map to secret
  if an item inside it is a secret.
  So I had to isolate the two test cases into separate outputs
  to get the plain text case to be written as a "value".
  If there's a more correct way of setting up that mock,
  I'm happy to merge the outputs back into a single map
  for a more representative test case.

Refs , 
2023-02-03 16:47:27 -08:00
Fraser Waters f8486ee056 Remove support for old NodeJS versions from function serializer 2022-12-11 21:20:06 +00:00
Justin Van Patten 31bf640375 [auto/nodejs] Test remote operations
Also cleans up some error messages to be consistent with the CLI and other languages.
2022-11-09 05:26:07 -08:00
Justin Van Patten 4873a7796b [auto/nodejs] Support for remote operations 2022-10-28 12:56:30 -07:00
Robbie McKinstry e978311216
Enable ESModule interoperability 2022-09-20 10:34:00 -04:00
Robbie McKinstry 76da04cf48
Move tracing module into cmd, since it should not be part of the library code. 2022-09-15 07:26:52 -04:00
Robbie McKinstry 1d246208d6
Make tracing conditional. Add gRPC instrumentation. 2022-09-15 07:26:52 -04:00
Robbie McKinstry 608086dd5e
WIP Add Jaegar-based tracing 2022-09-15 07:26:51 -04:00
Kyle Pitzen 490be1cc52
fix(automation): runPulumiCommand failed to call onOutput when provided () 2022-09-06 12:18:31 -04:00
Kyle Pitzen c4c46c3222
fix(ux): Adds a warning message when module resolution is ambiguous ()
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
2022-08-16 14:41:15 -04:00
Kyle Pitzen 83f3d6e260
chore(sdk/python): Deprecate PULUMI_TEST_MODE ()
chore(sdk/nodejs): Deprecate PULUMI_TEST_MODE
2022-08-16 09:25:52 -04:00
Michael Bridgen 10d4ef48f0
Include invoke.ts (and its type `InvokeOptions`) in generated documentation ()
* Make tsconfig.json valid JSON

* Include invoke.ts in tsconfig.files

.. and consequently, the type therein `InvokeOptions`, in generated
docs. All functions in Pulumi SDKs take an InvokeOptions-typed argument,
and all the generated documentation for those functions has a broken
link because it's not part of the NodeJS SDK documentation generated for
pulumi/pulumi.

The version of TypeDoc used is quite old, and I suspect it consults
`tsconfig.json` to find the source files (evidence: someone complaining
that it does not do this well enough:
https://github.com/TypeStrong/typedoc/issues/1515). I have
conservatively just added the file in question to `files`, since:

 - I'm not sure if .files should list _all_ the files
 - Upgrading TypeDoc would surely have many unintended consequences
2022-06-28 15:17:38 +01:00
Aaron Friel 9c1d7f9c89 ci: improve x-plat testing on Windows 2022-03-06 14:45:26 -08:00
Kyle Dixler c8280936dc
JavaScript fnSerialization match package.json exports ()
* Added support for complying with nodejs package.json exports field if provided.

Co-authored-by: Kyle Dixler <kyle@pulumi.com>
Co-authored-by: Ian Wahbe <ian@wahbe.com>
2022-02-08 10:22:56 -08:00
Pat Gavlin d3e49ecb65
[cli, testing, github] Gather code coverage data in CI. ()
These changes add support for gathering code coverage data during tests.

For tests that do not involve the Pulumi CLI, this is straightforward: all of
the ecosystems we target already support gathering coverage data, and we follow
the rules accordingly. Support for each language is broken out into its own
commit.

For tests that do involve the Pulumi CLI, the picture is a bit more complicated.
Go does not make it trivial to perform a coverage-instrumented build (go build
does not have a -cover flag, for example). In lieu of official support, we abuse
go test -c and TestMain to produce a build of the CLI that supports collecting
and reporting coverage data.
2021-11-30 17:24:01 -08:00
Anton Tayanovskyy babedf5171
Ignore logflow args in Node providers ()
* Ignore logflow args in Node providers

* Add unit test, handle --tracing

* Add missing files

* Add CHANGELOG

* Lint
2021-07-26 19:52:59 -04:00
Paul Stack 3fad2e5329 Removing x namespace from go/python/nodejs automation packages () 2021-04-14 19:32:18 +01:00
Komal 768db3e067
[automation/nodejs] - Implement min version checking () 2021-03-22 23:04:36 -07:00
Evan Boyle 8c6865af29
Always read and write nodejs runtime options from/to the environment () 2021-01-26 14:59:32 -08:00
Justin Van Patten 918615f072
[sdk/nodejs] Implement getResource in the mock monitor ()
Otherwise, unit tests for programs that reference resources that have been registered with `registerResourceModule` fail with unhandled exceptions.
2020-12-10 09:30:34 -08:00
Justin Van Patten edc79325fe
Add support for getResource to Node.js SDK ()
And update Node's resource ref deserialization to match Python.

Also, fixed a bug in Python resource ref deserialization that I noticed.
2020-12-01 10:58:15 -08:00
Pat Gavlin 3d2e31289a
Add support for serialized resource references. ()
Resources are serialized as their URN, ID, and package version. Each
Pulumi package is expected to register itself with the SDK. The package
will be invoked to construct appropriate instances of rehydrated
resources. Packages are distinguished by their name and their version.

This is the foundation of cross-process resources.

Related to .

Co-authored-by: Mikhail Shilkov <github@mikhail.io>
Co-authored-by: Luke Hoban <luke@pulumi.com>
Co-authored-by: Levi Blackstone <levi@pulumi.com>
2020-10-27 10:12:12 -07:00
evanboyle 2d49cabf68 simplify project and stack settings impl 2020-10-08 12:19:01 -07:00
evanboyle 7d171917ea support inline programs for nodejs automation api 2020-10-08 12:19:01 -07:00
evanboyle 946c12c891 continue LocalWorkspace impl, add runPulumiCmd 2020-10-08 12:19:01 -07:00
evanboyle 2ace0b0234 StackSettings 2020-10-08 12:19:01 -07:00
evanboyle fa388380c4 LocalWorkspace.projectSettings() 2020-10-08 12:19:01 -07:00
evanboyle ebdd3c1053 project settings 2020-10-08 12:19:01 -07:00
Pat Gavlin 2585b86aa4
Initial support for remote component construction. ()
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 .
2020-09-07 19:33:55 -07:00
CyrusNajmabadi 66bd3f4aa8
Breaking changes due to Feature 2.0 work
* Make `async:true` the default for `invoke` calls ()

* Switch away from native grpc impl. ()

* Remove usage of the 'deasync' library from @pulumi/pulumi. ()

* Only retry as long as we get unavailable back.  Anything else continues. ()

* Handle all errors for now. ()


* Do not assume --yes was present when using pulumi in non-interactive mode ()

* Upgrade all paths for sdk and pkg to v2

* Backport C# invoke classes and other recent gen changes ()

Adjust C# generation

* Replace IDeployment with a sealed class ()

Replace IDeployment with a sealed class

* .NET: default to args subtype rather than Args.Empty ()

* Adding system namespace for Dotnet code gen

This is required for using Obsolute attributes for deprecations

```
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'ObsoleteAttribute' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'Obsolete' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
```

* Fix the nullability of config type properties in C# codegen ()
2020-04-14 09:30:25 +01:00
Pat Gavlin 682dced40b
Mock resource monitor ()
These changes add support for mocking the resource monitor to the NodeJS
and Python SDKs. The proposed mock interface is a simplified version of
the standard resource monitor that allows an end-user to replace the
usual implementations of ReadResource/RegisterResource and Invoke with
their own. This can be used in unit tests to allow for precise control
of resource outputs and invoke results.
2020-02-28 17:22:50 -08:00
Alex Clemmer a40008db41 `StreamInvoke` should return `AsyncIterable` that completes
A user who calls `StreamInvoke` probably expects the `AsyncIterable`
that is returned to gracefully terminate. This is currently not the
case.

Where does something like this go wrong? A better question might be
where any of this went right, because several days later, after
wandering into civilization from the great Wilderness of Bugs, I must
confess that I've forgotten if any of it had.

`AsyncIterable` is a pull-based API. `for await (...)` will continuously
call `next` ("pull") on the underlying `AsyncIterator` until the
iterable is exhausted. But, gRPC's streaming-return API is _push_ based.
That is to say, when a streaming RPC is called, data is provided by
callback on the stream object, like:

    call.on("data", (thing: any) => {... do thing ...});

Our goal in `StreamInvoke` is to convert the push-based gRPC routines
into the pull-based `AsyncIterable` retrun type. You may remember your
CS theory this is one of those annoying "fundamental mismatches" in
abstraction. So we're off to a good start.

Until this point, we've depended on a library,
`callback-to-async-iterator` to handle the details of being this bridge.
Our trusting nature and innocent charm has mislead us. This library is
not worthy of our trust. Instead of doing what we'd like it to do, it
returns (in our case) an `AsyncIterable` that will never complete.
Yes,, this `AsyncIterable` will patiently wait for eternity, which
honestly is kind of poetic when you sit down in a nice bath and think
about that fun time you considered eating your computer instead of
finishing this idiotic bug.

Indeed, this is the sort of bug that you wonder where it even comes
from. Our query libraries? Why aren't these `finally` blocks executing?
Is our language host terminating early? Is gRPC angry at me, and just
passive-aggrssively not servicing some of my requests? Oh god I've been
up for 48 hours, why is that wallpaper starting to move? And by the way,
a fun interlude to take in an otherwise very productive week is to try
to understand the gRPC streaming node client, which is code-gen'd, but
which also takes the liberty of generating itself at runtime, so that
gRPC is code-gen'ing a code-gen routine, which makes the whole thing
un-introspectable, un-debuggable, and un-knowable. That's fine, I didn't
need to understand any of this anyway, thanks friends.

But we've come out the other side knowing that the weak link in this
very sorry chain of incredibly weak links, is this dependency.

This commit removes this dependency for a better monster: the one we
know.

It is at this time that I'd like to announce that I am quitting my job
at Pulumi. I thank you all for the good times, but mostly, for taking
this code over for me.
2019-11-12 13:51:19 -08:00
CyrusNajmabadi b135af10be
Enable full strict mode. () 2019-09-11 16:21:35 -07:00
CyrusNajmabadi e61f8fdcb8
Update us to the same target ES version that Nodejs uses. () 2019-09-10 16:19:12 -07:00
Luke Hoban 8da252270f
Fix tsconfig.json ()
Missing files here lead to docs not being included.  In particular, docs for `interface CodePathOptions` were missing.
2019-08-05 11:55:55 -07:00
CyrusNajmabadi 93f0bd708d
Add helper function for merging ResourceOptions () 2019-07-29 12:01:10 -07:00
CyrusNajmabadi e558296afa
Add a helper function to easily convert async functions to sync functions () 2019-07-16 12:12:21 -07:00
Alex Clemmer 3fc03167c5 Implement `cmd/run-policy-pack`
This command will cause `pulumi policy publish` to behave in much the
same way `pulumi up` does -- if the policy program is in TypeScript, we
will use ts-node to attempt to compile in-process before executing, and
fall back to plain-old node.

We accomplish this by moving `cmd/run/run.ts` into a generic helper
package, `runtime/run.ts`, which slightly generalizes the use cases
supported (notably, allowing us to exec some program outside of the
context of a Pulumi stack).

This new package is then called by both `cmd/run/index.ts` and
`cmd/run-policy-pack/index.ts`.
2019-07-16 00:58:33 -07:00
Luke Hoban 15e924b5cf
Support aliases for renaming, re-typing, or re-parenting resources ()
Adds a new resource option `aliases` which can be used to rename a resource.  When making a breaking change to the name or type of a resource or component, the old name can be added to the list of `aliases` for a resource to ensure that existing resources will be migrated to the new name instead of being deleted and replaced with the new named resource.

There are two key places this change is implemented. 

The first is the step generator in the engine.  When computing whether there is an old version of a registered resource, we now take into account the aliases specified on the registered resource.  That is, we first look up the resource by its new URN in the old state, and then by any aliases provided (in order).  This can allow the resource to be matched as a (potential) update to an existing resource with a different URN.

The second is the core `Resource` constructor in the JavaScript (and soon Python) SDKs.  This change ensures that when a parent resource is aliased, that all children implicitly inherit corresponding aliases.  It is similar to how many other resource options are "inherited" implicitly from the parent.

Four specific scenarios are explicitly tested as part of this PR:
1. Renaming a resource
2. Adopting a resource into a component (as the owner of both component and consumption codebases)
3. Renaming a component instance (as the owner of the consumption codebase without changes to the component)
4. Changing the type of a component (as the owner of the component codebase without changes to the consumption codebase)
4. Combining (1) and (3) to make both changes to a resource at the same time
2019-05-31 23:01:01 -07:00
Joe Duffy 644d5dc916
Enable unit testing for Pulumi programs ()
* 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
2019-04-16 22:20:01 -07:00