npm Blog (Archive)

The npm blog has been discontinued.

Updates from the npm team are now published on the GitHub Blog and the GitHub Changelog.

Customer Convo: Max Antoni, JavaScript Studio

image

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?

A. Hi 👋, I’m Max from JavaScript Studio. I’m currently forming a startup around a cloud service that scans JavaScript modules for runtime errors.

How’s your day going?

It’s going great! Calm enough to get some work done.

Tell me the story of npm at your company.

I want to share my work early with interested developers, but I also want to avoid running my own infrastructure. So I’ve set up the npm @studio Org where I can publish packages privately and manage who can install and/or publish.

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

It’s really a story about many packages, because I prefer slicing projects into small parts. This usually means a lot of setup, like cloning multiple git repositories and linking them. With private packages you can clone a single repository, run `npm install`, and you’re good to go. It makes modular projects more approachable.

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

Yes, I’m planning to open source as much of my work as possible. There are three questions I ask: 

• Is it general purpose?

• Is the scope of the module well-defined?

• Does the current form of the project provide value?

Especially the first point is important. It makes little sense to open source projects that are only useful in the context of JavaScript Studio. To give an example, I have a couple of projects that allow me to run parts of my AWS setup offline. I use them to run tests or when coding at the airport. They are general purpose, the scope is clear, and they (hopefully) provide value to others. I’m planning to open source those.

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

I think the main use case is sharing your work privately with no hidden costs like infrastructure maintenance. It’s also nice to know I can easily open source a project any time by flipping a switch.

How’s it going? How’s the day to day experience?

It’s 100% reliable. I never had a single service issue. It just works™.

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

I think it could be easier to add people to teams with “install only” roles. In a first step, I want to allow others to install my modules, but not necessarily publish new versions.

A nice feature would be notifications, like desktop notifications or Slack integration. If someone publishes a module in my org, I’d like to be notified.

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

If there are no objections to uploading packages to npm, it’s just the easiest way to get started for small teams. Especially if you have little capacity for infrastructure maintenance.

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

I started open sourcing the ground work projects that are used by most of the modules making up JavaScript Studio.

The first one is a release tool that integrates with the `npm version` command to prepare a changelog from git commits. I make all my releases with this tool:

https://www.npmjs.com/package/@studio/changes

The second project is a tiny JSON logger with a fancy emoji featuring formatter:

https://www.npmjs.com/package/@studio/log