Customer Convo: Dan Gebhardt, Cerebris

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 there! I’m Dan Gebhardt. I’m a co-founder of Cerebris, which is a small web application consulting firm I run with my brother Larry Gebhardt. We’re pretty heavily into open source — I’m on the core teams for Ember.js, Glimmer.js, the JSONAPI spec, and Orbit.js.

How’s your day going?

Whew, it’s a hot one today in New Hampshire! But things are going well. I’m putting some finishing touches on a docs site for Orbit, which feels good because it’s been so long in the making.

What is your history with npm?

Although I’ve been working on web apps for a very long time, I haven’t done much Node development. As a result, I’ve only become a regular npm user in the past few years as it’s gained traction for front-end development. During that time, I’ve been really pleased to see how quickly npm has matured. And not just the npm service, which seems to have scaled quite well, but also the CLI, which is getting both faster and more deterministic (yay lockfiles!). 

What problem did you have that npm Orgs helped you fix?

Tom Dale and I started developing Glimmer.js as a standalone component library separate from Ember in late 2016. Although Ember itself is architected very modularly, the core framework does not feel very modular in practice because of the way it is currently published and typically consumed. When building Glimmer.js we quite deliberately decided to package and publish it as modularly as possible from the start. We not only wanted to share as much as possible between Ember and Glimmer — we also wanted to make packages as useful as possible on their own.

We chose to publish all of the core Glimmer packages through the @glimmer Org. This means that “official” packages all get an authoritative scope that differentiates them from non-scoped community packages. Furthermore, developers can use different packages, such as the dependency injection library @glimmer/di, independent from the rest of Glimmer.

How’s the day-to-day experience of using Orgs?

There’s very little friction to working with Orgs. As the rest of the Ember core team has gotten involved in developing Glimmer, assignments and authorization have been simple and straightforward. As packages are published, core team members are automatically assigned rights, which reduces the overhead of creating and managing packages. 

The only extra thing to remember about scoped packages is that they are private by default. So it’s necessary to explicitly publish packages with public access using `npm publish –access=public`. This is not a problem though, since you only have to remember this on the initial publish (and it’s no doubt a good safety check).

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

I like using the npm CLI to manage packages, teams, and assignments, but a more interactive dashboard would be nice. Have I mentioned Ember.js? ;)

Would you recommend that other groups or companies use Orgs?

Most definitely. I can recommend Orgs for multi-package open source projects, even if they only have one member, because of the clarity that scoped packages provide to a community. Once you have multiple developers working on a project, you also gain the benefits of permission management. And even though I’ve only used Orgs for open source packages, I can easily see wanting to use private Orgs as well to get the same benefits for proprietary code.

What’s your favorite npm feature/hack?

I’ve become a real fan of using lerna for multi-package “mono-repos.” Lerna nicely solves the problem of managing dependencies across several local packages. Instead of needing to `npm link` them all individually, lerna can link them all together with one “bootstrap” command. It’s also quite useful for publishing multiple packages at once.

What is the most important/interesting/relevant problem with the JavaScript package ecosystem right now? If you could magically solve it, how would you?

A few months ago I would have said lockfiles, but I’m grateful that yarn and npm 5 have jumped that hurdle already. 

Instead, I’ll give a rather boring answer: I think we need more rigorous conventions for defining the entry points to our packages. In this era of advanced build tooling and transpilers, the current conventions around defining `main`, `module`, and even `types` in `package.json` seem inadequate. Stronger conventions could identify distributions by language (e.g., TypeScript), language level (e.g., ES5), and module format (e.g., commonjs). This would allow for automatic discovery of the least lossy version of sources appropriate for any given application, and allow for the most optimized JavaScript to be shipped to browsers using tools like babel-preset-env.

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

Nothing specific to npm tooling, just lots of exciting stuff happening in the @glimmer, @ember, and @orbit Orgs :)