Process Manager is now lib/process-manager.js
It's been entirely rewritten to reflect what I think a process manager
API should look like.
In particular, there are now two Process Managers, QueryProcessManager
and StreamProcessManager.
Pass QueryProcessManager a pure-ish query function (sync or async) that
takes a JSON value and returns a JSON value, and PM.query() will
execute that function in a subprocess, and return a Promise for its
return value.
StreamProcessManager is the same idea: Pass it a function to create an
ObjectReadWriteStream, and PM.createStream() will create a stream in a
subprocess and return a stream connected to it.
This is an update to match how Streams work: .read() returns a string,
and .readBuffer() returns a Buffer.
Being able to statically predict what type .read() will return is
really useful to TypeScript, in addition to being generally useful for
readability.
As a side benefit, readTextIfExists() is renamed readIfExists().
Now, seeds are passed as arrays, rather than needing to pass an entire
PRNG object. In addition, they're now passed in the options object,
instead of as a separate argument.
This is done mostly so the Miracle Eye can be rewritten with a custom
seed, which requires fewer turns and should overall be faster. Which
was in turn done because a Miracle Eye timed out on Travis CI earlier.
Overall, the speed increase is pretty negligible, so this is mostly
just about improving the test API.
Latest research (http://www.smogon.com/forums/posts/7625046/) shows that although Z-Synthesis bypasses Heal Block, using Z-Copycat to copy Synthesis does not. (Z-Copycat on a damaging move does of course turn into a damaging Z-Move.)
I've finally been sufficiently frustrated by Node's Streams API to
straight-up write my own.
This is what a Streams API looks like when you don't try to pretend
Promises don't exist. So much easier to use.
NPM's official documentation says that package-lock.json should be part
of the repository.
Why? `package-lock.json` is basically a snapshot of the `node_modules/`
directory. You can think of it like `node_modules.zip`, except more
human-readable, and requires an internet connection to unzip.
The main advantage of adding it to Git is that it lets you know exactly
the state of `node_modules/` at the time the programmer commits it. So
if a dependency breaks, it's easier to trace exactly when it broke.
It also makes sure `node_modules/` is exactly the same between
different development environments, so differences don't cause bugs to
appear for some developers but not others.
This comes with a number of disadvantages. The biggest one is that it
causes package-lock changes to appear in random commits, which can
outright lead to merge conflicts. Not to mention making diffs in
general significantly less readable.
And a lot of stated advantages aren't actually true (paraphrased):
> If I install express ^4.15.4, and later express 4.15.5 is released,
> a contributor would run `npm install` and gets 4.15.5, we would
> have different versions.
Like, this is intended behavior. If I didn't want that behavior, I'd
specify the express version as 4.15.4 instead of ^4.15.4. We can still
have the same version if we just re-run `npm install`, which we would
STILL have to do if we were using a package-lock file. The
package-lock file does not improve this situation.
(A Dev poll showed that most devs were in support of this.)
