We’re beginning to adopt Pulumi more broadly withi...
# general
We’re beginning to adopt Pulumi more broadly within our organization. As such, we’re needing simple abstractions that can be re-used across projects, namely helper functions to create opinionated AWS and Kubernetes providers (we just fetch kubeconfigs from S3 and create k8s providers accordingly). I’m just working in a single repository that contains multiple subdirectories, each containing their own Pulumi project. I’d like to create
, then install it by adding something like
"lib": "file:../lib"
to my
in each of the other directories. However, I don’t want this lib to define provider versions, rather I’d like the lib’s
to simply reference
of the referenced Pulumi providers. However, when I do this, pulumi fails to preview thanks to
error TS2307: Cannot find module '@pulumi/aws|kubernetes'.
This is probably just a Typescript question, but surely there’s a way to tell typescript that the types referenced in the libs should refer to the types defined in the project package.json.
are you creating ComponentResources? life gets a whole lot easier if you do that, you can just do
npm install ../common/fargate_webapp/
Well, I think I’d have the same issue. The “common” lib would have to have the providers installed by version, right?
Ideally, they’d only be referenced as PeerDeps.
Sure, I could wrap the creation of my providers in a ComponentResource and return them as outputs. Not a bad idea. 😛 Was just exporting functions that return the providers.
with a ComponentResource you can create your own package with provider versions for each Component
or are you trying to keep the same version across all?
Yea, that’s the idea. The lib doesn’t specify a version; just implies the consuming project has them installed.
hrm not super familiar with that, will do some reading and see if I can come up with an answer
Ultimately, it’s just the version of the SDK, not the actual provider runtime version, yeah?
That said, I don’t want to run into this version conflict scenario, cuz our libs and consuming projects will get stale. 😛
the provider runtime and sdk should be the same