rhythmic-finland-36256
01/27/2020, 3:05 PMComponentResources
which is a nice way of abstracting a certain part of the whole into a separate file. This makes the projects more readable as we now can find resources easier than in a long list of resources inside a single index.ts file. As we also started using pulumi for more than just one project, I’d like to be able to reuse those components in other projects without copy/pasting single classes between them (which is already way better than to copy/paste many lines of resources from an index.ts).
So I’m looking for some hints on how to share those javascript/typescript files via npm. I already know a bit about npm publishing, but I’m specifically interested in how to deal with the dependencies my code has on pulumi classes and how the project setup generally looks. I assume those classes would go into a simple node project (not a pulumi project) with a common tsc
step.
• Is there some best practice project structure for such ComponentResource
libraries?
• How do you deal with testing the resources if there is no pulumi project? Having a separate repo for the pulumi project that uses the library via npm link?
• How to handle dependencies on pulumi resources? I assume the library should not bring specific versions of pulumi providers with it? Is using peerDependencies
the way to go?limited-rainbow-51650
01/27/2020, 3:41 PMrhythmic-finland-36256
01/27/2020, 3:45 PMbest-summer-38252
02/11/2020, 9:27 AMrhythmic-finland-36256
02/24/2020, 12:42 PM@pulumi/kubernetes@1.4.5
in my package.json
- should this exact version be given to the user of my module, too? Maybe the user started yesterday and already uses @pulumi/kubernetes@1.5.1
which has some bugfixes. Not sure how this behaves then.limited-rainbow-51650
02/24/2020, 12:51 PMpackage.json
like "@pulumi/kubernetes": "^1.4.3"
but do not publish a lock file to the registry. The given version specifier uses 1.4.3 as the minimum version but will use a later 1.4.x version when availablerhythmic-finland-36256
02/24/2020, 12:56 PMnpm ci
over npm install
. When someone else installs my library, they will have their own lock-file tracking also transitive dependencies, right?@pulumi/kubernetes
but might choose the version on their own?limited-rainbow-51650
02/24/2020, 1:13 PMrhythmic-finland-36256
02/24/2020, 1:39 PMboundless-airport-99052
02/25/2020, 8:17 AMHow to deal with testingI have a nested pulumi project that imports the component in parent folder
import * as lib from '../index'
And before releasing the component, I do unit tests on the component itself and do a pulumi preview
on the pulumi project. I think I can go further by doing a real pulumi up
and pulumi destroy
during testing phase.
How to handle dependenciesFor the moment, I only add
@pulumi/*
dependencies as devDependencies
and let main project configure dependencies version. But I’m not sure it’s the best way to deal with dependencies, especially if you publish your component publicly