Commit Graph

55 Commits

Author SHA1 Message Date
Julien 7fd6726479
Pass through pluginDownloadURL in invokes ()
Fixes https://github.com/pulumi/pulumi/issues/16909

---------

Co-authored-by: Fraser Waters <fraser@pulumi.com>
Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-08-09 14:43:48 +00:00
Julien a3c0ea5455
Add NodeJS test for parameterized providers ()
This takes https://github.com/pulumi/pulumi/pull/16392 and updates local
SDK generation for nodejs and adds parametrisation support for invokes

---------

Co-authored-by: Fraser Waters <fraser@pulumi.com>
Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-08-09 08:34:29 +00:00
Thomas Gummerer 6215d96730
implement invoke transforms for NodeJS ()
Similar to what we recently did for Go in
https://github.com/pulumi/pulumi/pull/16617, also implement invoke
transforms for NodeJS
2024-07-18 08:41:39 +00:00
Will Jones 26ff81961b
Improve TypeDocs for `sdk/nodejs/runtime` ()
This commit improves the TypeScript TypeDocs for `runtime` 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.
2024-07-15 11:27:47 +00:00
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
Fraser Waters 6f9d0e85ba
Cleanup so uses of `any` in the nodejs sdk ()
Just fixing up some `any` uses to their actual types. One instance of a
missing undefined check.
2024-03-02 00:00:57 +00:00
Fraser Waters 65b8f5c841
Split CallRequest into ResourceCallRequest ()
<!--- 
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. -->

Similar to what we did to the `InvokeRequest` a while ago. We're
currently using the same protobuf structure for `Provider.Call` and
`ResourceMonitor.Call` despite different field sets being filled in for
each of them.

This splits the structure into `CallRequest` for providers and
`ResourceCallRequest` for the resource monitor. A number of fields in
each are removed and marked reserved with a comment explaining why.

## 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-08 13:16:23 +00:00
Fraser Waters eb4bec4dce
Update node sdk to use typescript definitions for grpc and protobufs. ()
Updates the node SDK to have types for the generated protobufs and grpc
services. No more `any`.

I don't think these types show up on any user facing parts of the SDK.
The two places they could show up are the mock monitor (but I've left
that as any for now) and the provider interfaces (which I've also left
alone for now).

But this fixes up most of our sdk internal code to have types, which
flagged a couple of oddities like assuming `Input<string>` was `string`
in the alias code, and a whole load of missing undefined checks.
2023-12-04 15:22:44 +00:00
Robbie McKinstry d6fd384e63
Eliminate unnecessary double negations.
This commit removes instances of prefix-!! where the value
would already be coerced into a boolean. It also removes
instances where the "optional chaining" operator (?.)
would suffice.
2023-05-09 18:35:59 -04:00
Robbie McKinstry e05a3bd81c
Apply autoformat
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.
2023-04-28 18:27:10 -04:00
Zaid Ajaj 5022d9d29e Add InvokeSingle variants to dotnet and nodejs SDKs 2022-12-06 22:15:40 +01:00
Daniel Bradley 350274c996
Tidy Nodejs SDK imports ()
* Remove unused nodejs SDK imports

Quick audit to find all unused imports in files

- Remove unused `protobufjs` dependency - we use `google-protobuf` and `@grpc/grpc-js`.

* Eliminate additional unused code
2022-05-30 09:31:28 +01:00
Fraser Waters 32dcaa58d6
Monitor.Invoke and Provider.Invoke take different arguments () 2022-04-14 10:59:46 +01:00
Aaron Friel 25bde5717d fix: respect plugin download URLs in nodejs SDK 2022-02-01 11:28:33 -08:00
Ian Wahbe 9a5ba09f47
[sdk/nodejs] Add pluginServerURL ()
* Add pluginServerURL to the nodejs SDK

Tests that this work are included in the PR.

* Update CHANGELOG_PENDING.md

* Add codegen change

* Add codegen test results

* Support invoke

* Setup defaults for InvokeOptions
2022-01-10 15:54:41 -08:00
Justin Van Patten 0b9e41e8c4
[sdk/nodejs] Marshal output values ()
This change adds support for marshaling outputs as output values in the Node.js SDK.
2021-09-15 18:25:26 -07:00
Horace Lee a92a005d68
Use ESlint instead of TSlint ()
Migrated TSlint configs to ESlint ones using [tslint-to-eslint-config](https://github.com/typescript-eslint/tslint-to-eslint-config) tool, and refined the configs to better match the current coding style.

Changes:
- [member-delimiter-style](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/member-delimiter-style.md#options) that as suggested default for type definition to be  with `semicolon`
- Indentation fixes that is enforced by [eslint-indent](https://eslint.org/docs/rules/indent#options)
- Added dependencies for ESlint with Typescript
- Removed TSlint
2021-08-10 11:31:59 -07:00
Justin Van Patten c1f3e1c84b
[sdk/nodejs] Support for calling methods () 2021-07-07 16:03:56 -07:00
Levi Blackstone 4d48ee0517
Enable resource reference feature by default ()
* Enable resource reference feature by default

Unless the PULUMI_DISABLE_RESOURCE_REFERENCES flag
is explicitly set to a truthy value, the resource reference feature is now
enabled by default.

* Set AcceptResources in the language SDKs

This can be disabled by setting the `PULUMI_DISABLE_RESOURCE_REFERENCES` environment variable to a truthy value.

Co-authored-by: Justin Van Patten <jvp@justinvp.com>
2020-12-10 11:21:05 -07:00
evanboyle 7d171917ea support inline programs for nodejs automation api 2020-10-08 12:19:01 -07:00
Levi Blackstone 736019f7ce
Add support for streamInvoke during update ()
Previously, streamInvoke was only supported by
the query command. Copied the implementation
into the resource monitor, which will allow
streaming invoke commands to run during updates.

Also fixed a bug with cancellation of streaming
invokes. The check was comparing against a
hardcoded string, which did not match the actual
error string. Instead, we can rely on the error code.
2020-07-10 10:56:35 -06: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
CyrusNajmabadi d4aa5fe20d Switch to 'console.log' for our hang warning. Add warning to synchronous StackReference calls. ()
Codepaths which could result in a hang will print a message to the console indicating the problem, along with a link to documentation on how to restructure code to best address it.

`StackReference.getOutputSync` and `requireOutputSync` have been deprecated as they may cause hangs on some combinations of Node and certain OS platforms. `StackReference.getOutput` and `requireOutput` should be used instead.
2019-11-19 12:51:14 -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
Alex Clemmer e37d23d52d Don't attempt to deserialize empty invoke responses 2019-11-07 10:16:39 -08:00
Alex Clemmer 038f920dc3 Make `streamInvoke` gracefully-cancellable from SDKs
The @pulumi/pulumi TypScript SDK exposes `streamInvoke`, which returns a
(potentially infinite) stream of responses. This currently is _assumed_
to be infinite, in that there is no way to signal cancellation, and
prevents Pulumi from being able to clean up when we're finished using
the results of the `streamInvoke`.

This commit will introduce a `StreamInvokeResult` type, which is an
`AsyncIterable` that also exposes a `cancel` function, whih does just
this.

Use it like this:

    // `streamInvoke` to retrieve all updates to any `Deployment`, enumerate 0
    // updates from the stream, then `cancel` giving the Kubernetes provider to
    // clean up and close gracefully.
    const deployments = await streamInvoke("kubernetes:kubernetes:watch", {
        group: "apps", version: "v1", kind: "Deployment",
        break;
    });
    deployments.cancel();
2019-11-05 10:47:48 -08:00
Alex Clemmer f195cc0d4d Implement `StreamInvoke` 2019-11-05 10:47:48 -08:00
CyrusNajmabadi da1f27d3ab Remove errant console logging. () 2019-10-18 13:02:53 -07:00
CyrusNajmabadi b1f20115cf
Properly handle providers with unknown Ids () 2019-10-16 15:19:43 -07:00
CyrusNajmabadi 91addf2feb
New approach to move us to using `deasync` as little as possible (and with as little impact to users as possible). () 2019-10-14 22:08:06 -07:00
Pat Gavlin 3c03ee3bdd
Fix invoke error reporting. ()
- Report all failures
- Use appropriate member functions to access failure details

Fixes https://github.com/pulumi/pulumi-terraform/issues/396
2019-08-08 09:14:36 -07:00
Sean Gillespie ad32d9d8ac
Plumb provider version through language hosts to engine ()
* NodeJS: allow callers to override provider version

* Python: allow callers to override provider version

* NodeJS: add version for invoke

* Python: add version to invoke

* NodeJS: add tests for ReadResource

* Post-merge cleanup

* update doc comments
2019-04-23 11:02:51 -07:00
CyrusNajmabadi 27b04c4c62
Have child resources update their parent urn to include themselves in its dependencies. () 2019-02-21 20:18:29 -08:00
CyrusNajmabadi 5211954f3a
Break out Resource and Output into their own files () 2019-01-31 18:08:17 -08:00
Matt Ellis a627cf817a Ensure InvokeRequest is defined
InvokeRequest is defined in provider_pb.js not resource_pb.js. Require
that module instead.
2019-01-31 12:00:32 -08:00
Pat Gavlin 1ecdc83a33 Implement more precise delete-before-replace semantics. ()
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.

We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.

This is perhaps clearer when described by example. Consider the
following dependency graph:

  A
__|__
B   C
|  _|_
D  E F

In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.

In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 09:46:30 -08:00
CyrusNajmabadi 9a044ff865
make the context-param non-optional for debuggable promises. () 2018-11-24 18:57:17 -08:00
Sean Gillespie 6707accdc8
Get rid of waitForDeath ()
Instead of looping forever, due to some recent improvements in engine
error handling it's sufficient for a language host to exit cleanly with
a zero exit code when the resource monitor is shutting down.
2018-10-10 10:01:57 -07:00
Sean Gillespie 2d4a3f7a6a
Move management of root resource state to engine ()
* Protobuf changes

* Move management of root resource state to engine

This commit fixes a persistent side-by-side issue in the NodeJS SDK by
moving the management of root resource state to the engine. Doing so
adds two new endpoints to the Engine gRPC service: 1) GetRootResource
and 2) SetRootResource, which get and set the root resource
respectively.

* Rebase against master, regenerate proto
2018-09-18 11:47:34 -07:00
Pat Gavlin 58a75cbbf4
Pull default options from a resource's parent. ()
If a resource's options bag does not specify `protect` or `provider`,
pull a default value from the resource's parent.

In order to allow a parent resource to specify providers for multiple
resource types, component resources now accept an optional map from
package name to provider instance. When a custom resource needs a
default provider from its parent, it checks its parent provider bag for
an entry under its package. If a component resource does not have a
provider bag, its pulls a default from its parent.

These changes also add a `parent` field to `InvokeOptions` s.t. calls to
invoke can use the same behavior as resource creation w.r.t. providers.

Fixes , .
2018-08-10 16:18:21 -07:00
Pat Gavlin a222705143
Implement first-class providers. ()
### First-Class Providers
These changes implement support for first-class providers. First-class
providers are provider plugins that are exposed as resources via the
Pulumi programming model so that they may be explicitly and multiply
instantiated. Each instance of a provider resource may be configured
differently, and configuration parameters may be source from the
outputs of other resources.

### Provider Plugin Changes
In order to accommodate the need to verify and diff provider
configuration and configure providers without complete configuration
information, these changes adjust the high-level provider plugin
interface. Two new methods for validating a provider's configuration
and diffing changes to the same have been added (`CheckConfig` and
`DiffConfig`, respectively), and the type of the configuration bag
accepted by `Configure` has been changed to a `PropertyMap`.

These changes have not yet been reflected in the provider plugin gRPC
interface. We will do this in a set of follow-up changes. Until then,
these methods are implemented by adapters:
- `CheckConfig` validates that all configuration parameters are string
  or unknown properties. This is necessary because existing plugins
  only accept string-typed configuration values.
- `DiffConfig` either returns "never replace" if all configuration
  values are known or "must replace" if any configuration value is
  unknown. The justification for this behavior is given
  [here](https://github.com/pulumi/pulumi/pull/1695/files#diff-a6cd5c7f337665f5bb22e92ca5f07537R106)
- `Configure` converts the config bag to a legacy config map and
  configures the provider plugin if all config values are known. If any
  config value is unknown, the underlying plugin is not configured and
  the provider may only perform `Check`, `Read`, and `Invoke`, all of
  which return empty results. We justify this behavior becuase it is
  only possible during a preview and provides the best experience we
  can manage with the existing gRPC interface.

### Resource Model Changes
Providers are now exposed as resources that participate in a stack's
dependency graph. Like other resources, they are explicitly created,
may have multiple instances, and may have dependencies on other
resources. Providers are referred to using provider references, which
are a combination of the provider's URN and its ID. This design
addresses the need during a preview to refer to providers that have not
yet been physically created and therefore have no ID.

All custom resources that are not themselves providers must specify a
single provider via a provider reference. The named provider will be
used to manage that resource's CRUD operations. If a resource's
provider reference changes, the resource must be replaced. Though its
URN is not present in the resource's dependency list, the provider
should be treated as a dependency of the resource when topologically
sorting the dependency graph.

Finally, `Invoke` operations must now specify a provider to use for the
invocation via a provider reference.

### Engine Changes
First-class providers support requires a few changes to the engine:
- The engine must have some way to map from provider references to
  provider plugins. It must be possible to add providers from a stack's
  checkpoint to this map and to register new/updated providers during
  the execution of a plan in response to CRUD operations on provider
  resources.
- In order to support updating existing stacks using existing Pulumi
  programs that may not explicitly instantiate providers, the engine
  must be able to manage the "default" providers for each package
  referenced by a checkpoint or Pulumi program. The configuration for
  a "default" provider is taken from the stack's configuration data.

The former need is addressed by adding a provider registry type that is
responsible for managing all of the plugins required by a plan. In
addition to loading plugins froma checkpoint and providing the ability
to map from a provider reference to a provider plugin, this type serves
as the provider plugin for providers themselves (i.e. it is the
"provider provider").

The latter need is solved via two relatively self-contained changes to
plan setup and the eval source.

During plan setup, the old checkpoint is scanned for custom resources
that do not have a provider reference in order to compute the set of
packages that require a default provider. Once this set has been
computed, the required default provider definitions are conjured and
prepended to the checkpoint's resource list. Each resource that
requires a default provider is then updated to refer to the default
provider for its package.

While an eval source is running, each custom resource registration,
resource read, and invoke that does not name a provider is trapped
before being returned by the source iterator. If no default provider
for the appropriate package has been registered, the eval source
synthesizes an appropriate registration, waits for it to complete, and
records the registered provider's reference. This reference is injected
into the original request, which is then processed as usual. If a
default provider was already registered, the recorded reference is
used and no new registration occurs.

### SDK Changes
These changes only expose first-class providers from the Node.JS SDK.
- A new abstract class, `ProviderResource`, can be subclassed and used
  to instantiate first-class providers.
- A new field in `ResourceOptions`, `provider`, can be used to supply
  a particular provider instance to manage a `CustomResource`'s CRUD
  operations.
- A new type, `InvokeOptions`, can be used to specify options that
  control the behavior of a call to `pulumi.runtime.invoke`. This type
  includes a `provider` field that is analogous to
  `ResourceOptions.provider`.
2018-08-06 17:50:29 -07:00
Sean Gillespie b5e4d87687
Improve the error message when data source invocations fail () 2018-06-07 11:21:38 -07:00
joeduffy 5967259795 Add license headers 2018-05-22 15:02:47 -07:00
Sean Gillespie 68911900fd
Graceful shutdown ()
* Graceful RPC shutdown: CLI side

* Handle unavailable resource monitor in language hosts

* Fix a comment

* Don't commit package-lock.json

* fix mangled pylint pragma

* Rebase against master and fix Gopkg.lock

* Code review feedback

* Fix a race between closing the callerEventsOpt channel and terminating a goroutine that writes to it

* glog -> logging
2018-05-16 15:37:34 -07:00
Joe Duffy 28033c22bc
Allow multiple Pulumi SDKs side-by-side ()
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 .

This fixes  and .
2018-04-07 08:02:59 -07:00
Pat Gavlin a23b10a9bf
Update the copyright end date to 2018. ()
Just what it says on the tin.
2018-03-21 12:43:21 -07:00
CyrusNajmabadi 275670692b
Introduce Output<T> and update Resource construction code to properly handle it. ()
This PR adds a new formalisms at the Resource layer.  First all inputs to a Resource are typed as ```Input<T>```.  This is either a T, ```Promise<T>``
2018-02-05 14:44:23 -08:00
CyrusNajmabadi 1df66df250
Further simplification of resource RPC requests. () 2018-01-25 15:26:39 -08:00