[carapace]

The "deps portfolio" gets updated whenever the deps change. In practice the flow goes like this:

0. A dev wants to use a new dependency, likely after experimenting with it a little bit.

1. Preliminary evaluation, which includes a transitive dependency scan. ("Too many dependencies" is a valid fail condition all on it's own.)

2. If everything looks good we bring it and it's deps into our internal repo. This includes the plumbing to add it to our dev|test|production envs. (Using Docker or whatever.)

3. Now the devs can use it in code destined for prod. There's a nice page in the company wiki that lists the exact version(s) with links to the docs, bug trackers, mailing lists, etc. and also the internal company lore for that package.

It's tight.

- - - -

This might seem like a lot of work up front, but think about all the work it saves down the line.

[jfoster]

When one of the transitive dependencies fixes a security issue, is it then re-evaluated prior to being updated in the internal repo?

I'm guessing you work at a pretty large tech company. It seems wasteful that so many companies might be replicating this work. I wonder if there might be the opportunity for a body to review & approve packages on behalf of many companies. Perhaps npm will eventually move in this direction.

[carapace]

> When one of the transitive dependencies fixes a security issue, is it then re-evaluated prior to being updated in the internal repo?

Yes, but this is typically pretty low overhead. And when it's not, it usually means there is some issue that has to be addressed anyway.

> I'm guessing you work at a pretty large tech company.

I did once, but right now "we" is a tiny startup (we're using Elm and Erlang.)

> I wonder if there might be the opportunity for a body to review & approve packages on behalf of many companies.

Ideally, that's what Free/Open Source Software would be, eh?

In the old days there were "sysadmins", System Administrators, who handled a lot of this sort of thing.