Customer Convos #3: Jesse Pollak, Clef

This piece is a 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?

Hi! I’m Jesse Pollak and I’m one of the co-founders and the Chief Product Officer at Clef.

How’s your day going?

It’s going pretty well! Just ate a yogurt and apple :)

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

Just took a look back through our commit history. It looks like we started using npm to manage our frontend packages for Clef in February of 2014. At that point, we were migrating from a frontend that consisted of spaghetti jQuery code to React. We chose npm to manage our dependencies because it seemed like the obvious choice.

Two years later, in March 2016, I see our first commit that references a private package. At the time, we were starting to build a new product that required reuse of a bunch of frontend logic from our core Clef product. To solve that problem, we started breaking small components and libraries out of our code base into npm packages. We needed a place to publish them — but we didn’t want them to be public — so private npm packages in a @clef org was the obvious choice! Getting started was really easy and we had our first private package published in less than a day.

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

One of the coolest parts of Clef is the Clef Wave. We’ve written a bunch of front-end logic to render and animate the wave, but since it’s a core part of our system, we don’t want to publish it as open source, although we may soon :). We need to use the wave across a bunch of different products, and private packages let us use the npm infrastructure to develop, publish, and install the necessary packages to render and animate the Clef Wave without making the unminified source public.

Does your company do open source? How do you negotiate what you keep private and public?

We do do open source (you can check out our work here)! Generally, we publish anything that we think would be generally usable by a broader audience (i.e., React components, Flask libraries, etc.), but we don’t open source our core products. That’s changing with Instant 2FA though — we’ll be open sourcing the entire code base!

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

All the developer friendliness of open source on npm — without the open source! It makes developing, publishing, and installing private packages dead simple.

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

Great!

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

Everything works pretty great right now. The one thing that’s been frustrating, which I would like to see improved, is adding outside collaborators to private packages. We have some packages that we need to share with partners, and in the current organization model, we’d need to pay for every npm user in the partner organization as a part of our organization — that’s really frustrating!

Ideally, we’d be able to add anyone to a private package for free and it would only cost money if we needed to add them to our whole organization.

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

Yes! npm makes publishing JS (and other front-end related code) dead simple and everyone should be using it!