* First experiment: export a type directly, but still use require.
* WIP: Add lazy-loading to utils, build export list.
* Untested: add submodule export generation with lazy-loading
* WIP: Syntactically valid submodule export
* Add tests, finish submodExportList generation
* Clean up comments
* Fix compilation error
* WIP
* Lazy-load class modules and re-export them
* Revert original approach
* Handle the class-with-method case eagerly
* Accept codegen
* Fix typo in method namespace condition
* Fix lazyLoadProperty to call require() in source context
* Support lazy-loading function modules
* Revert useles diff, PR feedback
* Remove extra ws diff
* Remove unused
* Accept codegen output
* Function-only files still need utilites import
* Optimize for not loading enums all the time
* Improve further
* Accept codegen
* Implement flags to control lazy-loading
* Accept codegen tests
* Illustrate on azure-native-nested-types
* Test lazy-loaded functions on output-funcs
* Start factoring out
* More cases
* More unit tests
* Reduce flag surface
* Separate fileInfo structs into its own module
* Merge lazyloads
* Accept codegen changes
* CHANGELOG
* Lint
* Revert caching require()
* Accept codegen
Co-authored-by: Robbie McKinstry <robbiemckinstry@Robbies-MacBook-Pro.local>
Co-authored-by: Robbie McKinstry <robbiemckinstry@macbook-pro.mynetworksettings.com>
* Add version (when env var is set)
* Correct python pypi implementation
* Add a test
* Update CHANGELOG_PENDING.md
* Set as language option
* Remove version.txt from .gitignore
* Add go support
* Correctly handle nodejs.pluginVersion
* Add a test demonstrating the problem
* Fix the bug
* Accept changes over the example set
* Accept go changes
* Accept python codegen; avoid nil lang info panic
* Accept .NET changes, compile
* Accept docs changes
* Add changelog notes
* Fix lint
* Add parens sparingly
* Flatten unions
* PR feedback
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.
* 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>
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.
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.
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.
- Add support for constant values in unions (e.g. `"foo" | "bar"`)
- Generate `Input<T | U>` instead of `Input<T> | Input<U>`
- Emit deprecation messages for resources
- Handle nil state inputs
- Allow packages to provide a README
- Remove sync invoke support
These changes are part of
https://github.com/pulumi/pulumi-terraform-bridge/issues/179, and
restore functional parity with the current `tfgen` generator.