Fix lockfile and undo npm dedupe

[christianbundy]

Resolves #1008 (maybe? pending review!)

My theory is that this was caused by npm dedupe which allowed flumeview-hashtable to use atomic-file@2.x.x, but this should be resolved now with the new lockfile:

$ npm ls flumeview-hashtable atomic-file
ssb-patchwork@3.12.0-alpha.3 /home/christianbundy/src/ssbc/patchwork
├─┬ flumeview-reduce@1.3.16
│ └── atomic-file@2.0.0 
├─┬ ssb-gossip@1.0.10
│ └── atomic-file@1.1.5 
└─┬ ssb-server@14.1.12
  ├─┬ ssb-db@19.1.1
  │ ├─┬ flumeview-hashtable@1.0.4 
  │ │ └── atomic-file@1.1.5  deduped
  │ └─┬ flumeview-reduce@1.3.16
  │   └── atomic-file@2.0.0 
  ├─┬ ssb-gossip@1.0.9
  │ └── atomic-file@1.1.5 
  └─┬ ssb-ooo@1.2.2
    └── flumeview-hashtable@1.0.4  deduped

Sort of a bummer that we can't trust npm dedupe but npm ls clearly shows a bunch of missing dependencies after running it. Boo, hiss.

[black-puppydog]

This seems to fix the issue! :)
For one machine, I had to scrap the flume log and rebuild, but now I have restarted it a couple of times without it complaining, and published messages in the meantime.

On the other hand, both those machines now consistently show the "Welcome, please enter your initial name & bio" modal when they start up. But the identity is the right one.

I need some serious shut-eye now. Will pick this up again tomorrow.
By the way: I monitor the index status, simply with watch -n 5 -c -d 'sbotc status | jq -C .progress.indexes'.
Is it normal that I start and current are way below target on startup, even they were all three equal when the app shut down? It feels like there might be some unnecessary indexing work being done there.

[christianbundy]

On the other hand, both those machines now consistently show the "Welcome, please enter your initial name & bio" modal when they start up. But the identity is the right one.

I saw that problem too, but after waiting for indexing and then restarting a few times it seems to be resolved now and I can't figure out how to reproduce it. I'm hoping it was a weird race condition while the flumeview-hashtable bug was fixing itself? I wish I knew, the Scuttlebutt stack can make for a very opaque debugging experience sometimes.

Is it normal that I start and current are way below target on startup, even they were all three equal when the app shut down?

Nope, that's funky. I noticed the same thing a couple of weeks ago but ended up having a bunch of trouble reproducing it. I've reopened #935 so that it's on everyone's radar, thanks for validating my sanity!

[christianbundy]

Confirmed: this is caused by ssb-server being shrinkwrapped downstream. Depending on github:ssbc/ssb-server#no-shrinkwrap resolves the problem and allows us to use npm dedupe again. 🙄

[black-puppydog]

I was pretty certain that "shrinkwrapped" was a metaphor, but now it reads like an actual build step. I'm glad someone here seems to understand what's happening...