Version 3.19 introduces breaking changes by changing a name

[addisonj]

It looks like version 3.19 introduces a breaking change (at least one, haven't checked for others)

Specifically, it seems like the serviceAccount module (in both nodejs and golang) was renamed to serviceaccount

We were allowing for new minor versions, but this change broke the expectation that minor versions won't change APIs

[komalali]

So, there are a couple of changes that unfortunately led to this.

1. Normalization of module names: [codegen/{go,nodejs,python}] Normalize modules. pulumi#5006 which changed the name of serviceAccount to serviceaccount. But since we weren't deleting the generated files before codegen, the stale files continued to exist in the folder.
2. Delete generated files before codegen: Clean codegen dir before regenerating pulumi-terraform-bridge#236, which removed the now stale serviceAccount directory.

The second change is what actually caused the break, but those files were already stale (codegen had already started using serviceaccount). It's not immediately clear how we can fix this since these changes were merged 4 weeks ago. Working on a solution.

[albertpx]

There is a similar issue using python. service_account was changed to serviceaccount. The previous import method does not work:

  File "./components/service_accounts_binding.py", line 2, in <module>
    from pulumi_gcp import service_account, projects
ImportError: cannot import name 'service_account' from 'pulumi_gcp' (/usr/local/lib/python3.7/site-packages/pulumi_gcp/__init__.py)

[stack72]

Hi @addisonj / @albertpx

We must apologise for the breaking change that occurred in the minor version bump
of the GCP provider. v3.19.0 introduced a codegen change that ensured consistent
package names.

This changed the following package names:

Go serviceAccount -> serviceaccount
NodeJS serviceAccount -> serviceaccount
Python service_account -> serviceaccount

This was an unintended consequence of the codegen change being released and is something
that we should have ensured happened in a controlled manner rather than forcing the
breakage on the customer

We are going to have a followup post-mortem event to ensure we learn from this and
that we add better quality bars to our releases so that we don't release these
breaking changes without any warning or notice. We will publish the results of this
post-mortem to make sure our customers understand what we have learned from this

I am sorry for this issue. If this issue will cause you any unnecessary replacement of
any infrastructure, then please do let us know and we can work with you on making sure this
isn't the case

Paul