Also includes a decent amount of refactoring to bring it in line with Showdown code standards.
---------
Co-authored-by: Slayer95 <ivojulca@hotmail.com>
ESLint has a whole new config format, so I figure it's a good time to
make the config system saner.
- First, we no longer have separate eslint-no-types configs. Lint
performance shouldn't be enough of a problem to justify the
relevant maintenance complexity.
- Second, our base config should work out-of-the-box now. `npx eslint`
will work as expected, without any CLI flags. You should still use
`npm run lint` which adds the `--cached` flag for performance.
- Third, whatever updates I did fixed style linting, which apparently
has been bugged for quite some time, considering all the obvious
mixed-tabs-and-spaces issues I found in the upgrade.
Also here are some changes to our style rules. In particular:
- Curly brackets (for objects etc) now have spaces inside them. Sorry
for the huge change. ESLint doesn't support our old style, and most
projects use Prettier style, so we might as well match them in this way.
See https://github.com/eslint-stylistic/eslint-stylistic/issues/415
- String + number concatenation is no longer allowed. We now
consistently use template strings for this.
* Sim: Use a CSPRNG
* Add test
* fix test prng
* move prng test to others
* fix slight hack
* tf?
* Fuck this
* fucking lol
* fix crap
* i'm going to kill someone
* i hate state
* fix test
* Good work genius
* typo
* Fix exportinputlog
* Refactor for inputlog backwards compatibility
This is a pretty major refactor which is mostly unrelated to the
feature, but it does make the code a lot simpler.
* Readability pass
* Readability (again)
* Remove sodium-native dependency
* Refactor to serialize seeds in hex strings
(Also removes the Buffer dependency from PRNG, and slightly improves
comments.)
* Apparently << is 32-bit signed
* Readability
---------
Co-authored-by: Guangcong Luo <guangcongluo@gmail.com>
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.
