Customer Convo: Clemens Stolle, Civey

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, and what your company does? 

A: Hi, I’m Clemens and I’m the lead frontend developer at Civey in Berlin, Germany. We do representative online opinion research. Anyone can embed our widget in their website to allow their users to take part in over 500 polls on a variety of topics.

How’s your day going?

I’ve just spent the last few hours optimizing our webpack config, but besides that I’m doing great. ;) The weather is starting to get nicer here in Berlin and the weekend is just around the corner. Also, we released some exciting new features this week and are working on even more. 

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

We’ve been using npm in our daily frontend workflow from the start of the company. That’s how we handle all of our dependencies, build steps etc.

We started out with just one product - our voting widget. When we started building our webapp shortly thereafter, we quickly noticed that we’d like to share some parts of the authentication logic or the api interaction layer.

So we moved them to separate git repositories and specified them as dependencies in our package.json. With more and more packages being split out we wanted to get proper releases and versioning. This is where private packages on npm came into play. 

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

We recently launched a third product which we call “Analytics Widget” and are working on refactoring our website. We quickly noticed that we would like to reuse and share a lot of our already existing UI components. So we started setting up a UI component library and published it as a private npm package. While our other internal libraries could potentially be open-sourced at some points, branded and very specific UI components aren’t of great value for the wider community. They are of great value to my team, though, as it allows us to build up a solid foundation for our user interfaces. One of our developers just replaced all of the forms in our webapp with a new, redesigned implementation in a matter of hours. This was possible because moving code to a separate module makes you think about the API you expose. If it’s well designed, reusing it becomes almost trivial.

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

We currently do not maintain any open-source projects, but our developers are encouraged to contribute to the libraries we use. In the future we’re looking to potentially extract useful libraries out of our products.

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

As a JavaScript developer, you probably know and love a lot of npm modules. Sometimes you want to share a piece of code, but cannot open-source it. With private packages, it’s just an ‘npm install’ away. Another aspect of using modules is a better structure of your code. You can split out pieces of functionality, write tests and forget about it. As I mentioned above it makes you think about abstractions and boundaries differently which can help make you a better developer. 

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

Publishing and installing private packages works flawlessly and is lightning fast. We rarely have to think about it, because we automatically publish from our CI system. For us as developers the npm CLI tool has really made a big step forward with v5 and is a pleasure to work with. Private packages aren’t any different to work with than open-source packages. You just have to remember to put your org scope in the package name. This makes them really pleasant work with as most JavaScript developers are already familiar with open-source npm modules.

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

From the point of view of our CTO the organization administration, the UI on the npm website could be improved. It is a little barebones with regards to managing billing etc. Also, more fine grained access token management would be valuable for our CI system.

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

If your org or company has multiple projects that share code that can’t be open-sourced (yet), npm private packages are the best solution to keep them organized. Each module can have proper tests, be integrated in CI flows and get correctly versioned releases. This will allow developers to confidently make changes in a large system and update modules with care. Additionally, a lot of JavaScript developers are already familiar with npm’s ecosystem which makes onboarding a breeze. For most of our projects it essentially just takes an `npm install && npm start` to get started.

Any cool npm stuff your company has done publicly that you’d like to promote? 

No, but if you speak German feel free to check out our service, answer some questions and get realtime representative opinion data on all kinds of interesting topics. ;)