Previous NPM package had a postinstall script that made it fail to
install. This fixes that.
TypeScript types still aren't working, as I suspected. That will
come in a future version.
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.)
Permessage-deflate is an extensIon that compresses websocket messages with zlib.
SockJS already supports it (indirectly) and the client's load balancer already
inserts the header in the opening handshake when making a WebSocket connection.
Config.wsdeflate makes this optional and allows tweaking the extension's resource
usage.
Modern versions of npm have made it less and less tenable to have
truly optional dependencies, so we'll just bite the bullet and let
people have slightly slower installs in exchange for not having to
deal with npm weirdness.
The new FS module is an abstraction layer over the built-in fs module.
The main reason it exists is because I need an abstraction layer I can
disable writing from. But that'll be in another commit.
Currently, mine is better because:
- paths are always relative to PS's base directory
- Promises (seriously wtf Node Core what are you thinking)
- PS-style API: FS("foo.txt").write("bar") for easier argument order
- mkdirp
This also increases the minimum supported Node version from v6.0 to
v7.7, because we now use async/await. Sorry for the inconvenience!
This also drops the mock-fs-require-fix dependency
mock-fs-require-fix was always kind of a huge hack. It's no longer
necessary, with an FS API that does everything it used to.
This removes a lot of other hacks from test/main.js, which is nice.
