* Add test case
* Fix tests
* Add test dependencies correctly
* Feed through error handling
* Include test output
* Get types to line up
* Add remaining test files
* Update changelog
* Correctly find type paths
* Handle transitive objects
* Handle required fields
* Add required+default test case
* Don't `<any>` cast known types.
* Add plain object to env-helper test
This test fails right now. My next problem is fixing it.
* Handle plain types
* Handle function inputs
* Fix the indentation
* Handle output types correctly
* Remove unnecessary `!`
* Add missing change to fix test
* Run tests with merge
* Merge in next _index.md diff
* Another attempt at _index.md
* Make module generation deterministic
* Fix docs generation
Credit to @praneetloke
* Allow non-pulumi imports for Node.js
Currently the code generator is assuming that Node.js dependencies are
following a naming scheme that is prefixed with `pulumi/`. If this is
not the case the generated import statement is incorrect.
This commit adds a map `ProviderNameToModuleName` to the language
definition that allows you to map the name of the extracted provider of
a dependency to a module name that the generator now uses to create the
import statement.
* Prepend "pulumi" to import names in Node.js SDK
It is common when writing multi-language components to have a module
name which conflicts with a provider name. This can produce unusable
code, since you cannot simultaneously import a package as `aws` and have
a namespace `aws`, for example.
This commit makes this situation much less likely, by renaming the
imported identifier for providers to `pulumiX` where it would
previously have been `x`.
This has an unfortunate side effect of making the examples in the
documentation slightly uglier, since import statements for third-party
packages are now of the form `import * as pulumiAws from "@pulumi/aws"`.
I don't see a way to discern whether code generation is for SDKs vs
examples however, and short of plumbing that through, I don't see a way
around this, so test expectations are updated accordingly.
Co-authored-by: Ben Schiborr <bschiborr@apple.com>
In Go, resource types are modeled as pointers, but there were cases where the type was not being emitted as a pointer, leading to panics and marshaling errors in programs. Additionally, array and map values that are external references were being emitted as pointers, but only resources should be pointers (not types), regardless of whether the resource type is external or local.
See #6200 for a complete description of the issue. In short, we generate
inconsistent names for object types depending on whether or not they are
transitively reachable from resources or functions, which risks
unintentional breaking changes due to schema updates.
1. Name "input" types differently: `TArgs` for a type that is used in
resource inputs, having `Input<T>` properties, and `T` for a type
that is used in invoke inputs. The same schema type can produce both.
2. Always keep the name `T` for output types, avoid appending `Result` to
the name.
3. As needed, introduce a flag in the existing providers' schemas to avoid
breaking changes. Consider removing it on a major version bump.
Fixes#6200.
