The npm Blog

This piece is part of our Customer Convos series. We’re sharing stories of how people use npm at work. Want to share your thoughts? Drop us a line.

Q. Hi! Can you state your name and what you do?

A. Phil Schleihauf, co-founder and developer at OpenRide.

How’s your day going?

Great, thank you! Hope yours is good too :)

Tell me the story of npm at your company. What specific problem did you have that private packages and orgs solved?

We’ve been node/react server/client since day 1, so we naturally used npm to manage dependencies. Private npm packages let us move code outside our private monorepo, so client and server could depend on specific versions, de-coupling library development from synchronization with the app.

Can you tell us a story about a specific package you wanted to make that private packages really enabled you to do?

We wrote our own testing framework. The intent was to open-source it eventually, but keeping it private let us design it in private, slack on documentation, not fix bugs, etc., until we had a solid design to clean up and release publicly.

We intended to move more things out of the monorepo into private packages, but in the end, did not.

Does your company do open source? How do you negotiate what you keep private and public? (Feel free to be as vague as you need to be)

Yes. We discuss it case-by-case. We’re definitely biased toward open-sourcing everything, but we also like to release things that we feel meet a level of quality that we’re happy with, and things that we intend to maintain.

To people who are unsure what they could use private packages for- how would you explain the use case?

To me, the killer use-case is code reuse. Moving shared code to a library vastly decreases friction around updating that library—it can have its own fast CI, its own releases whenever it wants, and app code can upgrade to the latest version at leisure. It’s nice to be able to get that for code that’s not suitable for open-source, whether because it’s too domain-specific, just-not-ready, or whatever.

I want to stress the joy of a separate CI. Our main app’s CI takes 12–20mins to run. Our private package runs in under a minute. Moving stuff out of our monorepo to their own fast CI has a positive dev-happiness effect!

How’s it going? How’s the day-to-day experience of using private packages and orgs?

Good. There is friction—new devs need to have npm accounts and permissions have to be set up for them. CI and build pipelines need to log in to pull the private dependencies, which required some hacks when we set it up. But those are all fixed-cost (or per-dev) items, and the benefits are worth it.

How would you see the product improved or expanded in the future?

I don’t think we’ve caught up to private orgs yet—I think we had to set up an “organization user” when we were getting things up and running, so I’d have to get up to date before answering this :)

Would you recommend that another org or company use private packages or orgs and why?

I would ask about their deploy/CI setup first. If they can get the keys/passwords in the right place at the right time easily, then I’d recommend it. So for example, at least at the time I set things up, we couldn’t get a Docker auto-build to work. We keep secrets in our CircleCI environment variables, and have a script that builds our Docker images in that environment instead.

Any questions I didn’t ask that you wish I did? Please ask/answer them here!

Q: What’s the difference between a hippo and a zippo? A: One’s really heavy, the other is a little lighter.