In the past, we used non-type-aware linting in our pre-push hook, as
well as in `npm test`. This was for performance reasons.
In practice, though, we use an eslint cache, which makes even
type-aware incremental linting instantaneous. My rule is that you
should be able to make a small change and lint in under 10 seconds, and
`npm test` should take under 30 seconds, and linting with no changes
(for the pre-push hook) should be under 2 seconds. This is still true
for type-aware linting, so there's no actual need for fast linting.
We've also switched to using `--max-warnings 0` to convert warnings to
errors. This seems to allow them to use the same cache file.
A big improvement here is that `npm test` should now be enough for
testing. I think everyone ran `npm run full-test` for a while because
`npm test` didn't have type-aware lint errors, but now that it does,
you'll be able to use it again and have your tests run a lot faster.
This is mostly just a follow up to #6342.
`prefer-optional-chaining` was turned on and fixed in every location it
complained in. The transformed function [0] looks expensive from a
glance but from skimming through the replaced sites it doesn't appear
to be ran in any important place, so it should be OK.
The linter improvements are:
- Increase linter performance
- Make `full-lint` and `lint` write to different caches so we
avoid overwriting their caches since they're different configs
- Change husky's hook to `npm run lint` so as to write to the
same cache
- Remove `@typescript-eslint/eslint-plugin-tslint` which is
essentially a wrapper to TSLint because the rules aren't worth
running another linter
- Convert `.eslintrc.json` and `.eslintrc-syntax.json` to two spaces
rather than four tabs to respect PS' `.editorconfig`
- Rename `fulllint` to `full-lint` to ease spelling it
[0] - https://pastie.io/mmtxpf.js (prettified)
`node tools/set-import [version]` can be run to create a
`@pokemon-showdown/sets` package containing sets from Smogon, usage
stats and third party sources. Some notes:
- The build is set up so that `tools/set-import/importer.ts` is
compiled to `tools/set-import/importer.js` - creating a
`.tools-dist/set-import` directory for the sole artifact was
deemed to be overkill
- The sets package is generated such that it can be used easily on
Node or in a browser (where the large set JSON can be loaded
asynchronously)
- Supported tiers/formats are mostly arbitrary - those popular
enough to have a signficant playerbase or analyses on Smogon have
been included, but additional formats can be added based on demand
- Some set information is redundant for ease of use by downstream
users: certain formes are split out and information that could
theoretically be inferred like level/ability/HP IVs are included
to simplify parsing logic and make the sets more immediately
available. This results in what should mostly be negligible
size overhead.
- In a similar vein, display versions of effect names instead of IDs
are used (name -> ID is trivial, ID -> name requires data lookup)
- All sets pass validation, provided certain simple transformations
are applied (eg. reverting `battleOnly` formes like Megas)
This tool has primarily been tested to run on Linux - running on
other platforms is not guaranteed to result in error-free output.
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.)
JSHint's ES6 support is shaky, and its development has stalled as of late.
Since ESLint can do by itself both JSHint and JSCS' jobs, this commit replaces them.
Gulp and its related dependencies are also hereby removed.
This cache is quite awful (welcome to the world of Node.js, I guess),
but at least it works. It has few flaws, like not being able to GC
unused cache files. Still, has to work for now. Changes syntax test
times from 10 minutes on my very slow laptop to 0.6 seconds.
(I wonder how this will work with Travis...)
Later I will try to figure out why JSHint is so unbelievably slow.
- /static/custom.css is now located at /config/custom.css
- /static/avatars/ is now located at /config/avatars/
- The redirect script now redirects all room URIs, not just the root
path. For example, if you are running a server on localhost port 8000,
visiting http://localhost:8000/teambuilder will now take you to the
teambuilder. This works for any room.
& and higher can change the list with /banword and /unbanword (or /bw and /ubw respectively). The words/phrases are turned into IDs (only lowercase alphanumeric characters allowed) and checked against the ID form of a given username.
Keep in mind the list has no sense of context, and so overzealous banning, particularly of short or otherwise common words, should be avoided. Or else user "Cofagrigus" will want to have a word with you.
