feat: add shim package re-exporting the provider constructor

[hagaym1]

Why

I'm building a Pulumi provider for Devin on the Pulumi Terraform Bridge, to be published under the community pulumiverse org (same as pulumiverse/pulumi-unleash, which I maintain).

The bridge generates its Pulumi schema and the .NET/Go/Node.js/Python SDKs by constructing the terraform-plugin-framework provider in-process, so it needs provider.New, which lives in internal/provider.

To be precise about the problem, since there is a workaround: the bridge can reach an internal constructor by declaring a synthetic module inside my repo whose module path is nested under yours (github.com/cognitionai/terraform-provider-devin/shim), plus a replace directive pointing it at a local directory. Go's internal-visibility check is on the import path, not the module, so that compiles. It's the pattern Pulumi's own boilerplate documents, and it's what I'll use if this PR isn't the right channel.

It's just not a nice arrangement: a third-party repo squats a module path in your namespace, and it silently breaks if internal/provider.New's signature moves. A 20-line package here makes the dependency explicit and reviewable on your side.

What

Adds shim/shim.go, a non-internal package that re-exports the constructor:

func New(version string) func() provider.Provider {
	return internalprovider.New(version)
}

shim.New returns exactly what main.go already passes to providerserver.Serve, so there is no behavior change, no change to any existing file, and nothing new in the provider binary's own code path.

This mirrors the equivalent change in the Unleash provider (Unleash/terraform-provider-unleash#307, merged 2026-07-29), which unblocked the Pulumi bridge there.

One ask, if you're open to it

The bridge has to pin a released version of this module. A tagged release containing this commit (rather than only a merge to main) lets the Pulumi provider depend on v0.2.1-or-similar instead of a pseudo-version. Happy to follow up whenever suits your release cadence.

Also worth flagging: this repo's history looks like a squashed export from an internal source of truth (Sync provider source). If that means external PRs aren't the right channel, just say so and I'll close this. The useful part is the 20-line file, however you'd prefer to land it.

[hagaym1]

@ctian1 @jeffy sorry to tag you directly, but I suspect pull requests on this mirror may not surface to
anyone. #2 has been open since mid-July with no comment, and #1 since mid-June, so I would rather ask
than let this sit indefinitely.

To be clear about the stakes: this is not blocking anything. The Pulumi bridge works today without
it, because a module declaring a path nested under this one's satisfies Go's internal-visibility rule.
Merging this only lets me delete that workaround, so "we will fold it into the next internal sync" or
"we would rather you keep the shim on your side" are both perfectly good answers.

The one thing that would help either way: if this repository is generated from an internal tree, could
you say so in the README or a CONTRIBUTING.md? Right now the history is three Sync provider source
commits, which leaves an outside contributor guessing whether a PR here is the right channel at all.

[hagaym1]

Following up with the piece that was missing when I opened this: the downstream consumer now exists and is published, so this is no longer a speculative request.

pulumiverse/pulumi-devin v0.1.0 shipped today, bridging this provider through the Pulumi Terraform Bridge:

• https://github.com/pulumiverse/pulumi-devin
• npm @pulumiverse/devin, PyPI pulumiverse-devin, NuGet Pulumiverse.Devin, Go github.com/pulumiverse/pulumi-devin/sdk

All 18 resources and 6 data sources map cleanly with no hand-written token overrides, so the Pulumi surface tracks this repo rather than reimplementing it.

To be straight about the urgency: this PR is not blocking anything. The bridge needs to construct the framework provider in-process to generate its schema, and internal/provider is unreachable from another module, so I worked around it with a small local module whose path is github.com/cognitionai/terraform-provider-devin/shim, wired in with a replace. Go checks internal visibility on the import path rather than the module, so that satisfies the compiler. It works, and it is what v0.1.0 ships with.

The reason it is still worth merging is that the workaround is a fake module standing in for a real one. Every consumer that wants to embed this provider has to reinvent it, and it silently breaks the moment internal/provider.New changes signature, because the shim is pinned to a require version rather than tracking your tree. Twenty lines here removes that for everyone.

The diff is one new file, no behavior change, no new dependencies (both imports are already in go.mod), and nothing existing is touched. It just re-exports the constructor main.go already calls.

One question, since every commit here is Sync provider source: if this tree is exported from an internal source of truth, shim/shim.go probably needs to live there to survive the next sync. No sync so far has removed a file, so it may well persist as-is, but you would know better than I do. Happy to move it wherever fits, or to close this and keep the workaround if you would rather not widen the public surface. A no is a perfectly good answer, I would just like to know which it is.

@jeffy @ctian1 tagging you as the two pushing the syncs. Also relevant to #2, which is in the same position.