https://pulumi.com logo
#typescript
Title
# typescript
r

rhythmic-finland-36256

01/27/2020, 3:05 PM
On publishing ComponentResources for reuse over several projects: We started modularizing our pulumi (typescript) projects using several
ComponentResources
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?
Is kubernetesx a good starting point for that? I don’t see any special handling for dependencies here. https://github.com/pulumi/pulumi-kubernetesx/blob/master/nodejs/kubernetesx/package.json
l

limited-rainbow-51650

01/27/2020, 3:41 PM
I’m also still in the investigation phase for such a setup. What I found so far is generally aimed at creating reusable NPM packages, but not having the overhead of a git repo per npm package. On my radar is: • Lerna: https://lerna.js.org/ • Yarn workspaces: https://legacy.yarnpkg.com/lang/en/docs/workspaces/ Both work fluently together: https://carloscuesta.me/blog/javascript-monorepos-lerna-yarn-workspaces/
r

rhythmic-finland-36256

01/27/2020, 3:45 PM
Thanks for that input. My goal is not only to being able to reuse those packages but also making some of them available publicly as there is not really much intellectual property in it and maybe someone else tackling the same problems (e.g. AKS cluster setups or general app/service-principal handling in Azure) might benefit and contribute to the project. If I understand it correct, this doesn’t have to be a conflict with the tools you mentioned, right?
Still there is the issue of how to deal with transitive dependencies so that the projects using the library can still progress individually from the library’s dependencies versions.
Anyone else thinking about releasing some helper packages to npm for reuse? We have some use cases for azure and kubernetes related `ComponentResource`s we use in several projects but need some assistance on doing things right when it comes to publishing modules for pulumi consumption. ⬆️
💯 1
b

best-summer-38252

02/11/2020, 9:27 AM
The pulumi module as a lib would need its entrypoint in the package.json and you can bundle it with webpack or rollup to address the transitive deps?
r

rhythmic-finland-36256

02/24/2020, 12:42 PM
My issue is not that I want to bundle any transitive dependency. Transitive dependencies should be handled fine by the package json of my bundle. My question is more about on which version of a pulumi dependency I should depend and how this affects somebody using the same dependency in another version. E.g. if I started to build some abstraction over a kubernetes object some weeks ago and used
@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.
l

limited-rainbow-51650

02/24/2020, 12:51 PM
@rhythmic-finland-36256 For a reusable package, I specify an open version in my
package.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 available
Fall back to the NPM docs to read up on version specifiers if you want to have another scheme: https://docs.npmjs.com/files/package.json#dependencies
r

rhythmic-finland-36256

02/24/2020, 12:56 PM
Why not committing the lock file? If I understand it right, the package-lock.json is only applied when using
npm ci
over
npm install
. When someone else installs my library, they will have their own lock-file tracking also transitive dependencies, right?
I didn’t fully read on the topic yet, but would peer dependencies be a thing for this use case if I want to specify that the user needs
@pulumi/kubernetes
but might choose the version on their own?
l

limited-rainbow-51650

02/24/2020, 1:13 PM
@rhythmic-finland-36256 if you provide the lock file in your package, you prevent users of using a new provider version.
r

rhythmic-finland-36256

02/24/2020, 1:39 PM
I mostly used node for scripting / web apis and of course pulumi programs but didn’t create libraries yet. That behaviour makes sense from a library user perspective, but also makes building the library a bit less deterministic then…
b

boundless-airport-99052

02/25/2020, 8:17 AM
Hi @rhythmic-finland-36256, I have published some pulumi component package in a private npm repository.
How to deal with testing
I 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 dependencies
For 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
👍 1
2 Views