@nwalters512 do you need to run npm i Locally to update the lock file?

npm ERR! cipm can only install packages with an existing package-lock.json or npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or later to generate it, then try again.

@adevick There's no package-lock.json checked into this repo. The last commit to this repo was ab7c53b, which removed package-lock.json, and from what I can see, no CI run has completed successfully since then. It seems like CI wasn't tested at all before that commit landed on master.

@bcoe can you say more about why this was closed? Is there anything I can do to help land this change?

I've pinged @bcoe on X .. we're also experiencing #1535 (or likely a variant thereof).

@kraenhansen thanks for the contribution. It looks like a few tests are failing, do you see this locally?

@bcoe this is my contribution; I'm looking into the failure right now!

@bcoe this is my contribution; I'm looking into the failure right now!

My bad sorry, I was half paying attention, and it was @kraenhansen who reached out to me.

I was able to fix one test failure cause, which was that foreground-child will overwrite process.exitCode; the correct way to specify a new exit code is to return one from the cleanup function. This was done in

The second failure relates to --show-process-tree, which now includes the "watchdog" process that foreground-child added in v3. I don't see an easy way to fix this; it will always be incompatible with snapshots because the process is invoked with a non-deterministic PID in its arguments. Any suggestions?

@nwalters512 two options:

1. I'd be fine with skipping those tests.
2. Alternatively, what I've done in the past is remove values from the string that's about to be snapshot with a string replace that vary.

(1) would seem to be the easiest, as https://github.com/istanbuljs/istanbul-lib-processinfo doesn't consistently order items in the tree, and the order actually changes the output of the lines we do want because of how the tree is rendered.

It's worth noting that this change will be visible to users, in the form of an extra line in the process tree like this:

├── node 88099
│     Unknown % Lines

We could conceivably catch that and filter it out by looking for something like this:

execArgv[0] === '-e' && execArgv[1].indexOf('foreground-child watchdog pid') !== -1

I'm not sure if that's worth the effort, or how brittle that would end up being in the long run if/when foreground-process changes. Might be worth checking with @/isaacs, who oddly enough both maintains foreground-process and requested the process tree functionality in the first place: #158

@nwalters512 the process tree is pretty niche, I'm comfortable with commenting out these tests as long as the majority of tests work that exercise core behaviour.

@nwalters512 friendly nudge on this one 😄

@bcoe I haven't forgotten about this! I'm AFK on my honeymoon, I'll be able to get back to this on the week of May 6. If there's an urgent need to land this in the meantime, don't hesitate to make changes on my behalf.

@nwalters512

I'm AFK on my honeymoon

Congrats!