- Split out common functionality into generateModuleContextMap method
- Add LanguageResource and LanguageProperty structs for use by downstream
codegen tools
- Add LanguageResources function for use by downstream codegen tools
This class was available in the pulumi.resource module, but was not exported from the core `pulumi` module as intended for all public APIs at this level.
Add support for union types that indicate a default type for targets
that do not support unions, or do not support unions in certain
positions (e.g. output properties). The NodeJS backend makes use of this
in combination with a new flag, `disableUnionOutputTypes`, to avoid
generating unions in output types.
These changes also refactor the various module ->
package/module/namespace mapping methods so that these entities can be
fetched by their language name rather than their token.
- Typecheck in all cases where a type may have changed
- Do not perform literal conversions if the type is already correct
- Perform literal conversions before checking to see if a call to
`__convert` is required. This catches cases such as string literals
passed where ints are required. Without this change, that form in
particular generates a bare number literal rather than a number
literal wrapped in a `__convert`.
If the source file for a resource or function definition would collide
with a reserved filename (e.g. `index.ts`), append an underscore to its
filename (e.g. `index_.ts`).
These changes are necessary in order to move tfgen over to the schema
code generator.
The schema generator for tfgen has an annoying behavior for nested types
in which it does not separate input and output types. Worse, the shape
of the type that results from a collision of input and output types is
order-dependent: whichever of the two was observed last wins (note that
the shape is still determenistic, as the order in which types are
recorded is always the same). As a result, the NodeJS code generator
needs to know the set of required properties for the other aspect of the
type in order to generate proper code.
Contributes to
https://github.com/pulumi/pulumi-terraform-bridge/issues/179.
Types like output(T), promise(T), and union(T_0, ..., T_N) should be
assignable from dynamic if they contain an element type that is
assignable from dynamic.
This allows consumers to use the following code to check if some type
behaves like the dynamic type w.r.t. conversions:
```
if t.AssignableFrom(model.DynamicType) {
}
```
Fixes#4703.
Types like output(T), promise(T), and union(T_0, ..., T_N) should be
assignable from dynamic if they contain an element type that is
assignable from dynamic.
This allows consumers to use the following code to check if some type
behaves like the dynamic type w.r.t. conversions:
```
if t.AssignableFrom(model.DynamicType) {
}
```
Fixes#4703.
The previous attempt to allow this didn't actually allow it, so this is
take two. As part of the previous attempt, I thought after tweaking the
test I had observed the test failing, and then succeeding after making
the product changes, but I must have been mistaken.
It turns out that our existing mocks tests weren't running at all
because of a missing `__init__.py` file. Once the missing `__init__.py`
is added, the tests run, but other tests ("test mode" tests) fail
because the code that creates the mocks and resources will run during
test discovery, and setting the mocks modifies global state.
To address the test issue, I've moved the mocks tests into their own
`test_with_mocks` package that can be run separately from other tests.
And addressed the original issue, by creating a root Stack resource if
one isn't already present when the mocks are set.
- Move the implementation of loadPackageSchema into a method on
PackageCache
- Protect the cache with synchronization primitives to enable
concurrency in downstream consumers
- Use jsoniter to deserialize schemas
