The npm blog has been discontinued.
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?
How’s it going? How’s the day to day experience of using private packages/orgs?
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?
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. ;)