This message was deleted.

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

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