Commit Graph

49 Commits

Author SHA1 Message Date
Aaron Friel 4756d45258
Fix TypeScript checking of Output maps of "any" values ()
This change fixes the TypeScript checking of output "any" maps.
Previously, as in the referenced issue, an `Output<Record<string, any>>`
had unusable properties with the lifting mechanisms in TypeScript. That
is, for such an output `foo`, using `foo["bar"]` would typically result
in a type error, as the type would be:

```typescript
pulumi.OutputInstance<unknown> | pulumi.Output<any>
```

This union type with unknown results in a type error on trying to use
`foo["bar"].apply(...)`. This is caused by the conditional type of
`Lifted<T>` having a condition `T[P] extends OutputInstance<infer T1>`
evaluating to the true branch, with `T1` inferred as `unknown`.

This is because `any extends OutputInstance<unknown>`.

Adding a strict check for `any` in the conditional type `Lifted<T>`
fixes the issue.

Fixes 
2024-08-15 19:09:21 +00:00
Will Jones 47fa329ad3
Improve TypeDocs for `sdk/nodejs` ()
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>
2024-07-15 09:05:28 +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
Aaron Friel eb80185b62
fix: advise people of the ESLint Plugin for catching interpolation issues ()
Raised by @lunaris in onboarding, we don't advertise the [Pulumi ESLint
Plugin](https://github.com/pulumi/eslint-plugin-pulumi). As using an
output in a template literal is one of the most common avenues to
discovering this issue, perhaps we should advertise the plugin here?

What's lacking from this is documentation, but I imagine that users will
see this, create issues, and that will drive improvements either in the
base SDK or the ESLint Plugin.
2024-06-21 08:16:29 +00:00
Will Jones e63ff72eda
Fix documentation comments in the NodeJS SDK ()
This commit fixes a few errant documentation comments that use `//`
instead of the recognised `/**`. This should hopefully improve
documentation generation as well as hover-over documentation provided by
e.g. TSServer.
2024-06-03 12:50:03 +00:00
Thomas Gummerer c91d40ac5f
allow unknowns in apply during update ()
Currently during updates we try to make the values known during apply,
even if they are marked unknown. This results in knows that should
really still be unknown.

Note that this behaviour is currently encoded in tests, which also
needed to change.
2024-04-10 16:48:38 +00:00
Mark Nevill 1b63aa7721
Add option to throw on output toString and toJSON calls ()
<!--- 
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

This adds an environment variable that changes output's `.toString` and
`.toJSON` methods to throw an exception instead of returning a string
containing a warning.

This feature mitigates the issue described in  by allowing users to
opt in to having accidental toString calls (e.g. in a JS backtick string
that is missing `pulumi.interpolate`) throw an exception. The behaviour
ends up similar to the `get()` method of outputs, which throws an
exception.

I don't know how to write tests for this change, or even test it
manually.

## 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
  - [ ] 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. -->

---------

Co-authored-by: Fraser Waters <frassle@gmail.com>
2023-12-20 11:43:07 +00:00
Christian Nunciato 202fbd946f Fix links outputs docs 2023-07-12 14:59:07 -07:00
Robbie McKinstry 9658df87e7
This commit safely replaces empty interfaces with type aliases.
Empty interfaces have no effect, even when they are subtyping
other interfaces. An empty interface is always equivalent to its supertype.
They can be safely replaced with type aliases, which better express
the semantic equivalence between the two types.
2023-05-11 23:10:00 -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
Fraser Waters 9fd6254f49 Add jsonParse to nodejs sdk 2022-12-28 09:30:24 +00:00
Fraser Waters 390dd988ab Add jsonStringify to nodejs sdk
This isn't _quite_ right, because you could possibly end up with an
output value being passed to stringify still via a custom replacer or
toJson method, and we don't handle that. But I don't think we _can_
handle that as we'd need async in sync to do it.
2022-12-09 11:37:18 +00:00
Daniel Bradley 072342e872
Remove undefined cases from inputs to `all` function
Using `all` currently looses type safety around the handling of input values which are possibly undefined.
By adding the explicit undefined option to each argument, the undefined case outside the inputty type does not get captured.

By removing the explicit `undefined` cases, the undefined is captured by the generic parameter and correctly carried through to the output type.

For example, if an input to `all` is possibly undefined, the value after `all` won't be labeled as possibly undefined.

```
// pulumi.Input<string> | undefined
let input = possiblyUndefinedInput();
// pulumi.Output<string>
let original = pulumi.all([input])[0];
// pulumi.Output<string | undefined>
let newBehaviour = pulumi.all([input])[0];

function possiblyUndefinedInput(): pulumi.Input<string> | undefined {
  return undefined;
}
```
2022-10-17 14:24:58 +01:00
Anton Tayanovskyy f6fc099792
Avoid importing typescript unless necessary ()
* 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
2022-07-20 17:38:55 -04: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
Pat Gavlin 55ecf7a81e
Run SDK lint jobs ()
Just what it says on the tin. Fixes .
2021-04-01 11:23:47 -07:00
Paul Stack ae9a6db36e
Add the ability to pulumi.unsecret an existing output ()
Related: 

This will take an existing output and then unwrap the secret, and
return a new output

```
import * as pulumi from "@pulumi/pulumi";

const x = pulumi.secret("test")
export const xVal = x;

const y = pulumi.unsecret(x);
export const yVal = y;
```

```
▶ pulumi stack output
Current stack outputs (3):
    OUTPUT         VALUE
    xVal           [secret]
    yVal           test
```

Also adds the ability to check if an output is as secret:

```
import * as pulumi from "@pulumi/pulumi";

const x = pulumi.secret("test")
const isSecret = x.isSecret;

export const isSecretDeets = isSecret;
```
2021-01-14 20:36:52 +00:00
Trung Lê 4362744a7d
Fix typo () 2020-08-11 12:12:24 +01:00
Pat Gavlin 7fff99d346
Do not allocate outputs for nested prompt values. ()
* Do not allocate outputs for nested prompt values.

Currently, `outupt`/`all` in the NodeJS SDK work recursively, allocating
outputs for every value at every depth, then collecting the component
promises into a top-level output. In the case of prompt values, these
nested outputs are not necessary, and allocating them can create massive
amounts of garbage. This appears to be the cause of
https://github.com/pulumi/pulumi-kubernetes/issues/963.
2020-02-04 19:21:37 -08:00
Justin Van Patten 9abcca345a
Mark internal APIs `@internal` to filter from API docs ()
Also:

 - Cleaned up existing tags so they're consistently at the bottom of doc comments where they should be
 - Cleaned up some unused imports while I was taking a pass over the files
 - Marked one function `@deprecated` that should be deprecated
2020-01-26 09:06:35 -08:00
CyrusNajmabadi 35bc41c5d3
Support sxs with old outputs with sync resources only. () 2019-12-17 19:04:09 -08:00
CyrusNajmabadi f4fc00ad0e
Output.apply should lift resources from inner Outputs to the top level output. () 2019-12-17 14:11:45 -08:00
CyrusNajmabadi 9151d48ee3
Fix typing for 'Lifted<T>' to work better across versions of TS () 2019-12-13 11:18:19 -08:00
CyrusNajmabadi ad4da29cbd
Expose lifted resource properties () 2019-12-09 17:42:13 -08:00
Pat Gavlin 137fd54f1c
Propagate inputs to outputs during preview. ()
These changes restore a more-correct version of the behavior that was
disabled with . The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.

By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.

Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.

These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
  callback should be run even if the result of the apply contains
  unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
  either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values

The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.

In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.

These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.

Fixes .
2019-11-11 12:09:34 -08:00
CyrusNajmabadi fd3b64dae8
Simplify Output.apply greatly () 2019-10-28 11:39:52 -07:00
Pat Gavlin 834e583c95
Revert "Propagate inputs to outputs during preview. ()" ()
This reverts commit 80504bf0bc.
2019-10-10 10:33:05 -07:00
Pat Gavlin 80504bf0bc
Propagate inputs to outputs during preview. ()
These changes restore a more-correct version of the behavior that was
disabled with . The original implementation of this behavior was
done in the SDKs, which do not have access to the complete inputs for a
resource (in particular, default values filled in by the provider during
`Check` are not exposed to the SDK). This lack of information meant that
the resolved output values could disagree with the typings present in
a provider SDK. Exacerbating this problem was the fact that unknown
values were dropped entirely, causing `undefined` values to appear in
unexpected places.

By doing this in the engine and allowing unknown values to be
represented in a first-class manner in the SDK, we can attack both of
these issues.

Although this behavior is not _strictly_ consistent with respect to the
resource model--in an update, a resource's output properties will come
from its provider and may differ from its input properties--this
behavior was present in the product for a fairly long time without
significant issues. In the future, we may be able to improve the
accuracy of resource outputs during a preview by allowing the provider
to dry-run CRUD operations and return partially-known values where
possible.

These changes also introduce new APIs in the Node and Python SDKs
that work with unknown values in a first-class fashion:
- A new parameter to the `apply` function that indicates that the
  callback should be run even if the result of the apply contains
  unknown values
- `containsUnknowns` and `isUnknown`, which return true if a value
  either contains nested unknown values or is exactly an unknown value
- The `Unknown` type, which represents unknown values

The primary use case for these APIs is to allow nested, properties with
known values to be accessed via the lifted property accessor even when
the containing property is not fully know. A common example of this
pattern is the `metadata.name` property of a Kubernetes `Namespace`
object: while other properties of the `metadata` bag may be unknown,
`name` is often known. These APIs allow `ns.metadata.name` to return a
known value in this case.

In order to avoid exposing downlevel SDKs to unknown values--a change
which could break user code by exposing it to unexpected values--a
language SDK must indicate whether or not it supports first-class
unknown values as part of each `RegisterResourceRequest`.

These changes also allow us to avoid breaking user code with the new
behavior introduced by the prior commit.

Fixes .
2019-09-30 11:03:58 -07:00
CyrusNajmabadi b84b3d487d
Revert "Simplify signature of `pulumi.all` ()" ()
This reverts commit b32892e0c1.
2019-05-28 10:54:56 -07:00
CyrusNajmabadi b32892e0c1
Simplify signature of `pulumi.all` () 2019-05-21 13:13:23 -04:00
Matt Ellis 825a461b2e Fix a SxS issue with `isSecret`
Because of our Proxy types, every output will return something when
you call `.isSecret` on it. However, if you call it on an output from
a version of `@pulumi/pulumi` which did not support secrets, the thing
you will get back is not undefined but rather an `Output` which wraps
undefined.

Because of this, care must be taken when reading this property and so
a small helper is introduced and used in places we care about.
2019-05-13 15:45:08 -07:00
Matt Ellis ade9cd4588 Flush out comment on isSecret promise 2019-05-10 17:07:52 -07:00
Matt Ellis 87bc7d443f Support Secret Outputs in the Node SDK
`Output<T>` now tracks if an output represents secret data or
not. When secret, it is marshalled as a secret value and we signal to
the resource monitor that it is safe to return secret values to us.

The `pulumi` module exports a new functiion, `secret<T>` which works
in the same was a `output<T>` except that it marks the underlying
output as a secret.

This secret bit flows as you would expect across `all`'s and
`apply`'s.

Note that in process memory, the raw value is still present, when you
run an `apply` for a secret output, you are able to see the raw
value. In addition, if you capture a secret output with a lambda, the
raw value will be present in the captured source text.
2019-05-10 17:07:52 -07:00
Justin Van Patten fedfc9b6b4
`pulumi update` => `pulumi up` ()
We changed the `pulumi update` command to be `pulumi up` a while back
(`update` is an alias of `up`). This change just makes it so we refer to
the actual command, `pulumi up`, instead of the older `pulumi update`.
2019-05-06 14:00:18 -07:00
CyrusNajmabadi a602cccc3e
Properly mark members as @internal () 2019-04-23 19:24:06 -07:00
CyrusNajmabadi 992952b54f
Revert "Better present interpolated strings during preview. ()" () 2019-03-26 16:36:43 -07:00
CyrusNajmabadi 718a0c293b
Better present interpolated strings during preview. () 2019-03-18 17:09:12 -07:00
CyrusNajmabadi d6d839608b
Tweak signature of .apply to help TS infer things better. () 2019-03-06 01:53:58 -08:00
CyrusNajmabadi 7f5e089f04
Update `@pulumi/pulumi` to version 0.17.0 ()
This update includes several changes to core `@pulumi/pulumi` constructs that will not play nicely
in side-by-side applications that pull in prior versions of this package.  As such, we are rev'ing
the minor version of the package from 0.16 to 0.17.  Recent version of `pulumi` will now detect,
and warn, if different versions of `@pulumi/pulumi` are loaded into the same application.  If you
encounter this warning, it is recommended you move to versions of the `@pulumi/...` packages that
are compatible.  i.e. keep everything on 0.16.x until you are ready to move everything to 0.17.x.

### Improvements

- `Output<T>` now 'lifts' property members from the value it wraps, simplifying common coding patterns.  Note: this wrapping only happens for POJO values, not `Output<Resource>`s. 

- Depending on a **Component** Resource will now depend on all other Resources parented by that
  Resource. This will help out the programming model for Component Resources as your consumers can
  just depend on a Component and have that automatically depend on all the child Resources created
  by that Component.  Note: this does not apply to a **Custom** resource.  Depending on a
  CustomResource will still only wait on that single resource being created, not any other Resources
  that consider that CustomResource to be a parent.
2019-03-05 17:06:57 -08:00
CyrusNajmabadi 0117c1c01d
Turn off warning for toString/toJSON on an Output () 2019-03-04 12:03:18 -08:00
CyrusNajmabadi 3bb8759b23
Implement rtti checks more consistently () 2019-02-28 14:56:35 -08:00
CyrusNajmabadi aa3c6d0ba6
Converting an Output to a string or JSON now produces a warning . () 2019-02-27 16:00:54 -08:00
CyrusNajmabadi 0d2d1eb61a
Rolling back toString/toJSON change ()
* Revert "Make toString and toJSON internal ()"

This reverts commit 7579b84f73.

* Revert "Update error message to point at docs. ()"

This reverts commit 9156c26a2e.

* Revert "Throw on Output.toString and toJSON ()"

This reverts commit c33b4505c0.
2019-02-27 14:53:56 -08:00
CyrusNajmabadi 7579b84f73
Make toString and toJSON internal () 2019-02-27 02:15:36 -08:00
CyrusNajmabadi 9156c26a2e
Update error message to point at docs. () 2019-02-27 01:45:26 -08:00
CyrusNajmabadi c33b4505c0
Throw on Output.toString and toJSON () 2019-02-26 19:24:21 -08:00
CyrusNajmabadi 967c6407a0
Revert "Simplify how we export the .all operator ()" ()
This reverts commit 93c9464125.
2019-02-23 19:54:28 -08:00
CyrusNajmabadi 93c9464125
Simplify how we export the .all operator () 2019-02-22 12:02:52 -08:00
CyrusNajmabadi 5211954f3a
Break out Resource and Output into their own files () 2019-01-31 18:08:17 -08:00