This commit adds two new fields to the Node package info struct to
permit setting the plugin name if it differs from the package name, and
the version if it differs from the package version. This was already
supported by the loader.
Coincident with the release of Pulumi 3.0, we updated the provider SDK codegen for Python to no longer use casing tables for translating Python snake_case names to Pulumi camelCase names (and vice versa). Instead, the mapping is encoded in decorators applied on class properties.
Some of the code that was used to generate and use the casing tables has persisted. This commits removes this code, as it's no longer necessary, and will improve the quality of our generated examples.
Collection types nested inside of Input<Union<...>> types need to abide
by the usual rules for collection types nested inside of input types.
These changes replace the use of the generic SimplifyInputUnion with a
.NET-specific simplifyInputUnion that does not remove Input types
inside of a union if those Input types wrap collection types. Retaining
these Input types allows the usual logic for handling
Input<Collection<...> types in typeString to kick in.
Fixes#7569.
- Only build casing tables once per package
- Right-size buffers in name generation
These changes lead to a significant speedup in example gen for
azure-native.
* 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>
- Lazily produce conversion failure diagnostics. This lowers the
allocation volume and cuts down on execution time by avoiding the
conversion of source and dest types to strings.
- Add a fast path for union conversions that checks if the source type
is identical to any of the union's element types. Type equality
checks are generally much faster than type conversion checks.
These changes lead to a significant speedup in codegen time in
azure-native.
- Track which languages have been imported for a package. If a language
has already been imported, do not re-run its importers.
- Track which package contexts have been loaded in the Go code
generator, and do not reload a context that already exists.
These changes shave a profound amount of time off of codegen in
azure-native, speeding things up by a factor of 5.
When converting a `schema.InputType` to a `model.Type`, calculate the
resolved form of the type in the schema type system rather than the
model type system. The results are semantically identical, but the
number of type objects that are allocated is much smaller b/c
`model.NewOutputType` no longer allocates.
This deserves a little more explanation.
In order to prevent nested outputs and/or promises, `model.NewOutputType`
calculates the resolved form of its argument prior to allocating a new
`OutputType` value. Calculating the resolved form of the argument is a
no-op if the argument is already fully resolved. Therefore, passing in a
fully-resolved schema type prevents `model.NewOutputType` from
calulating the resolved form, and `model.NewOutputType` will only
allocate the `OutputType` itself instead of the `OutputType` and the
resolved form of any eventuals present in its argument.
This has a _very important_ knock-on benefit: the schema -> model type
translator ensures that given a `schema.Type` instance `T` it will
always return the same `model.Type` instance `U`. This termendously
speeds up type equality checks for complex types, as they will now be
referentially identical.
This change alone gives a significant speedup in azure-native code
generation.
This commit modifies the generation of `setup.py` to use Python
variables as the source for the package version and plugin version
instead of placeholder strings. This has the effect of making the
packages installable via the `-e` flag directly from their source
directory rather than requiring a build step, which is useful while
developing a plugin and examples in tandem.
This commit modifies Go program generation to prevent producing array
and slice object elements as pointers in args structures, which fails at
runtime and does not make sense in any case. For example, in the case of
a type defined like this in schema:
```json
"statements": {
"type": "array",
"items": {
"$ref": "/aws/v4.8.0/schema.json#/types/aws:iam/getPolicyDocumentStatement:getPolicyDocumentStatement"
}
},
```
The following (which fails at runtime) was produced before this change:
```go
Statements []*iam.GetPolicyDocumentStatement `pulumi:"statements"`
```
And the following is produced after after this change:
```go
Statements []iam.GetPolicyDocumentStatement `pulumi:"statements"`
```
Test expectations are updated accordingly.
This commit fixes code generation for intermediate module paths to
produce valid TypeScript identifiers.
Before this change, the following (non-compilable) import was produced
in `./jetstack/certmanager/acme`:
```
import * as jetstack/certmanager/acme/v1alpha2 from "./jetstack/certmanager/acme/v1alpha2";
```
After this change, the following import is produced:
```
import * as v1alpha2 from "./v1alpha2";
```
This example is repeated at each level of the module tree. Test
expectations are adjusted to reflect this change.
This commit modifies the Go code generator to use configured aliases for
the root package name of a Go module. This is useful when a version 2
package is present, as it prevents generation of identifiers such as
"v2" which were produced by the old logic.
These changes add support for unmarshaling and marshaling package
schemas using YAML instead of JSON. Language-specific data is
canonically JSON. Users of the `*Spec` types will need to update the
types of the the their `Language` values to use the new
`schema.RawMessage` type instead of `json.RawMessage`: the former has
support for YAML while the latter does not.
This commit adds a newline to the end of the package.json files
generated by Pulumi codegen, such that they can be installed in place
without modification.
The inputs and expected outputs for the tests are encoded using a
schema. Each property present in the schema forms a testcase; the
expected outputs for each language are stored in each property's
`Language` field with the language name "test". Expected outputs can be
regenerated using `PULUMI_ACCEPT`.
Rather than duplicating the list of tests and codegen driver across each
SDK, move its definition into `pkg/codegen/internal/test`. This has a
few notable benefits:
- All SDK code generators will be tested against each test. Though some
tests may exercise a particular code generator more than others, the
extra coverage will be generally beneficial.
- Adding a new test is simpler, as only a single file needs to be
changed.
- All SDKs now honor the `PULUMI_ACCEPT` environment variable for
updating baselines.
- Codegen tests now validate all generated files instead of only a
particular subset.
These changes support arbitrary combinations of input + plain types
within a schema. Handling plain types at the property level was not
sufficient to support such combinations. Reifying these types
required updating quite a bit of code. This is likely to have caused
some temporary complications, but should eventually lead to
substantial simplification in the SDK and program code generators.
With the new design, input and optional types are explicit in the schema
type system. Optionals will only appear at the outermost level of a type
(i.e. Input<Optional<>>, Array<Optional<>>, etc. will not occur). In
addition to explicit input types, each object type now has a "plain"
shape and an "input" shape. The former uses only plain types; the latter
uses input shapes wherever a plain type is not specified. Plain types
are indicated in the schema by setting the "plain" property of a type spec
to true.
The `bad-methods-2.json` test ensures there is an error when trying to use a function as a method twice.
The schema looks like:
```
"methods": {
"bar": "xyz:index:Foo/bar",
"baz": "xyz:index:Foo/bar"
}
```
And the expected error is:
> function xyz:index:Foo/bar for method baz is already a method
However, when the schema is unmarshalled into a map, the keys in the map are unordered (just as JSON keys in objects are unordered), so occaisonally we'd see an error mentioning method `bar` rather than `baz`:
> function xyz:index:Foo/bar for method bar is already a method
To address this, we'll fix the portion of the code that is generating the error to walk the map in a deterministic order, and we'll also return the list of methods in the same deterministic order as well.
More testing has found further issues with incorrect attribute shapes
generated by tf2pulumi. This knob will allow us to continue to generate
examples until those bugs are fixed.
