Customer Convos: Paul Betts, Slack

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?

Hey all, I’m Paul Betts and I’m the lead developer on the Slack Desktop application.

How’s your day going?

Ugh pass, long story :)

What specific problem did you have that private packages and Orgs solved? Can you tell us a story about a specific package you wanted to make that private packages really enabled you to do?

The Slack Desktop app is an Electron app, so our app is of course 100% in with regards to the npm ecosystem. We publish our own public packages as well as use private packages.

In the Desktop app, we actually use private packages in a somewhat unusual way. In order to package the software needed for the Calls feature, we need to ship precompiled versions of our modified WebRTC, and to interface it with Electron, we write a native node module. We found that the easiest way to get that Node module to have the versions of WebRTC it needed was to make WebRTC itself a npm package, so that npm install just pulls everything in correctly and builds the Calls native module. Who knew that npm is a great C++ package system :)

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

We generally try to make anything public that we can in the Desktop team. Because our app is built on open-source, our contributions are a small way to repay the development community for enabling us to build this product. Generally, we choose to make things private when they don’t make sense for other people — i.e., if it has a change specific to our setup. We don’t want people to find a package and think, “Oh, this @slack version must be better / endorsed by Slack!” but instead it’s just weird and broken.

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

Any time you want to have private source code as an npm package, use Orgs and private packages.

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

Everything works great. It’s headache-free.

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

It’d be cool to think about how to support the “Temporary scoped package to work around PR” workflow — i.e.,

I submit a PR to an upstream project, “Hey, I fixed yr thing!”
Simultaneously if I need it faster, I change the name to “@slack/PACKAGE” and publish it myself with an alpha version.
I rig my project to use my private fork.
Maintainer merges my PR and publishes a new release.
npm, Inc. sees a new version of upstream, and npm deprecates mine and tells me to move to the new upstream one.

Might be a little too heavy for npm, Inc. to do, but thinking about that use-case of “scoped packages for temporary forks, that go away after awhile” would be something to explore.

Zomg, yes. I would love this.

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

Of course, if you need them they work great, and they don’t have the weirdo problems that pinning to git revisions have, like certain npm scripts not running.

Any questions I didn’t ask that you wish I did? Please ask!

Nope, we’re a fairly non-trivial project and npm’s CLI and package system has always had an answer for everything we’ve thrown at it, including per-platform packages. It’s really great.

So, finishing up, any cool npm stuff your company has done publicly that you’d like to promote?

We’ve published a bunch of public npm packages in the Desktop team. A mostly-complete list is at https://slack.engineering/building-hybrid-applications-with-electron-dc67686de5fb#.wbcehjpau