Skip to content

Conversation

@jkodroff
Copy link
Member

This commit adds a new "Packaging a Component" guide that provides a comprehensive comparison of three component packaging approaches: single-language, cross-language, and provider-based components. The guide helps users choose the right approach based on their team size, language diversity, and runtime requirements.

Changes:

  • Add packaging-a-component.md with detailed comparison guide
  • Add cross-language-components.md with implementation details
  • Remove duplicate cross-language content from components/_index.md
  • Update build-a-component.md to reference new packaging guide
  • Add cross-references in building-extending/_index.md and private-registry.md

The new guide includes decision criteria, advantages/limitations for each approach, and a summary table comparing key features.

Fixes #16795

This commit adds a new "Packaging a Component" guide that provides a
comprehensive comparison of three component packaging approaches:
single-language, cross-language, and provider-based components. The guide
helps users choose the right approach based on their team size, language
diversity, and runtime requirements.

Changes:
- Add packaging-a-component.md with detailed comparison guide
- Add cross-language-components.md with implementation details
- Remove duplicate cross-language content from components/_index.md
- Update build-a-component.md to reference new packaging guide
- Add cross-references in building-extending/_index.md and private-registry.md

The new guide includes decision criteria, advantages/limitations for each
approach, and a summary table comparing key features.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@claude
Copy link
Contributor

claude bot commented Jan 29, 2026

Documentation Review

This PR adds comprehensive component packaging guidance and successfully reorganizes cross-language content. The new structure improves discoverability and provides clear decision criteria for choosing packaging approaches.

Issues Found

Spelling Error

Line 83 in packaging-a-component.md:

For more information on submitting packages to the Pulumi Regisitry, see...

Issue: "Regisitry" should be "Registry"

Suggestion:

For more information on submitting packages to the Pulumi Registry, see [Publishing Pulumi packages](/docs/iac/guides/building-extending/packages/publishing-packages/).

Missing Leading Slash in Link

Line 83 in packaging-a-component.md:
The link path is missing a leading slash.

Current:

[Publishing Pulumi packages](docs/iac/guides/building-extending/packages/publishing-packages/)

Should be:

[Publishing Pulumi packages](/docs/iac/guides/building-extending/packages/publishing-packages/)

Inconsistent Terminology

Lines 65 and 67 in cross-language-components.md:
The heading uses "entry point" (two words) but the body text uses "entrypoint" (one word).

Current:

### Define an entry point

The entrypoint analyzes components...

Suggestion: Use "entry point" (two words) consistently throughout for better readability:

The entry point analyzes components to automatically build a schema, and interact with the Pulumi engine to manage the component lifecycle.

Positive Observations

  • Clear decision criteria with trade-offs well explained
  • Good use of cross-references between related content
  • Proper aliases added for moved content (SEO preserved)
  • Consistent heading capitalization (H1 title case, H2+ sentence case)
  • Comprehensive comparison table that helps users choose the right approach
  • Proper frontmatter structure in all new files

Summary

The reorganization successfully separates concerns: the main components page now focuses on concepts, the new cross-language-components.md covers implementation details, and packaging-a-component.md provides decision guidance. After fixing the three issues above, this PR will significantly improve the component documentation.


Please mention me (@claude) if you'd like me to review any updates or help fix these issues.

@pulumi-bot
Copy link
Collaborator

Copy link
Member

@iwahbe iwahbe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fuzzy on the difference between Cross-language components and Provider-based components. Everything else looks great.


## Adding multi-language support

By default, components are authored and consumed in the same programming language by extending the `ComponentResource` class. The class can then be imported or referenced using the language's applicable pattern. To support consuming components in other languages, Pulumi can introspect your component class and generate the necessary SDKs. To support multi-language consumption, a couple additional steps are required.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true in some languages, but not all languages.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Not all languages" -> We're talking about Go (b/c it doesn't have inheritance) and YAML, I presume?


In your component directory, create a `PulumiPlugin.yaml` file and specify the runtime the component is authored in.

{{< chooser language "typescript,python,go,csharp,java" >}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can also write components in YAML.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This content is temporary because it's already covered here (including YAML): https://www.pulumi.com/docs/iac/guides/building-extending/components/build-a-component/

We will de-duplicate the content in a fast-follow issue.


{{< /notes >}}

### Generating local SDKs with pulumi install
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you use pulumi package add, you don't need to run pulumi install as follow-up, since pulumi package add already generates the SDKs for you. pulumi install will actually re-generate them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix.

Provider-based components are built as full Pulumi [providers](/docs/iac/concepts/providers/). They compile to native binaries with no runtime dependencies and can include both [component resources and custom resources](/docs/iac/concepts/resources/#resources). Because provider-based components have a higher overhead for CI/CD and publishing, and in most cases are written in Go, they are a fit for very large organizations that have many teams using many different languages, or organizations where the runtime requirements for cross-language components are not suitable.

{{% notes type="info" %}}
If you want to create a component for public consumption and publish it in the [Pulumi Registry](/registry), you should create a provider-based component, author it in Go, and publish SDKs in the public feeds for each language (npmjs.org, etc.).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably the wrong place for this discussion, but we already allow components written in other languages in the public registry, and we shouldn't require that people publish SDKs in all languages.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pulumi package add will work for anything with a schema.

When considering provider-based components, bear the following tradeoffs in mind:

- **No runtime dependencies for consumers**: Consumers don't need Node.js, Python, or any other runtime installed because the provider plugin is distributed as a native binary
- **Full provider capabilities**: In addition to any components you want to include in the package, provider packages written in Go can also include custom resources that make direct API calls
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also true for "Cross-language components" written in Go. Go only has one library for authoring Pulumi resources, both custom & component.

- **Go strongly recommended**: Providers are usually written in Go because the Pulumi supported tooling makes maintaining the provider [schema](/docs/iac/guides/building-extending/packages/schema/) significantly easier compared to other languages (see note for details)
- **CI/CD Overhead**: Provider-based components typically have pre-published SDKs, which requires a more involved CI/CD process (including publishing to a package feed after a release)
- **Argument type limitations**: Because calls to provider-based components are serialized, there are some limitations on the types that can be included in the component's resources. For more information see [Component arguments and type requirements](/docs/iac/concepts/components/#component-arguments-and-type-requirements)
- **No Pulumi IDP support**: Cannot be published to Pulumi IDP Private Registry
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not true, they can be published to the IDP registry. I think they just don't display in IDP docs right now, but that may have changed. CC @fnune

…g-a-component.md

Co-authored-by: Ian Wahbe <me@iwahbe.com>
@pulumi-bot
Copy link
Collaborator

@pulumi-bot
Copy link
Collaborator

- Fix grammar: "an SDKs" → "SDKs"
- Fix typo: "Regisitry" → "Registry"
- Fix broken link: add leading slash to publishing-packages path

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Copy link
Contributor

@CamSoper CamSoper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've applied some minor style and formatting fixes. LGTM!

This is an excellent reorganization of the component packaging documentation. The new guide provides a clear decision framework for users choosing between packaging approaches, and the comparison table is particularly helpful.

Changes applied:

  • Fixed grammar: "an SDKs" → "SDKs"
  • Fixed typo: "Regisitry" → "Registry"
  • Fixed broken link: added leading slash to publishing-packages path

@pulumi-bot
Copy link
Collaborator

Copy link
Contributor

@CamSoper CamSoper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverting approval to test tooling -- No changes actually required.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Copy link
Contributor

@CamSoper CamSoper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Applied minor style fixes. LGTM! Excellent reorganization of the component packaging docs.

@pulumi-bot
Copy link
Collaborator

Copy link
Contributor

@kramhuber kramhuber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Killer. Really well done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Components: Packaging Components Guide

6 participants