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?

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/

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?

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?

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.

@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

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?

@rhythmic-finland-36256 if you provide the lock file in your package, you prevent users of using a new provider version.

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…

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