Now that [`lint` and `full-lint` use the same configuration](c57fcf25c6), the only difference between them is the `--max-warnings` flag.
This separation causes some problems:
- In small terminal windows, warnings can be obscured by terminal scroll due to the large volume of unit tests. These warnings in turn cause CI failures since GitHub Actions runs `full-lint`.
- When changes to the linting script need to be made, **three** scripts need to be updated. This can lead to oversights such as `full-lint` not being updated for `.tsx` files when JSX support was added.
The `no-extraneous-dependencies` rule conflicts with the way we use
`node-oom-heapdump`.
It also isn't even the kind of dependency linting we need! It's
obvious when we forget to include a dependency (CI will tell us), it's
forgetting to remove a dependency that can stick around unnoticed.
Anyway, this allows us to remove the entirety of `eslint-plugin-import`.
Yay for cutting down dependencies?
I've spent the past few weeks working on build systems for other
projects, and this has paid off in having a better understanding of
things here.
The NPM package should now be much easier to use now.
Major changes:
- TypeScript definitions (f47e38c5ad)
- Support for importing teams (ddb6010bb9)
- A CLI for exporting teams (ddb6010bb9)
- `lib/` available as an unstable API in the NPM package (147b7e01c9)
- Lots of documentation updates (a813a55679)
semver? what's that? Seriously, though, the major breaking changes
are all in undocumented APIs.
Notable changes include:
- A new Dex API (#8181)
- `lobby` is no longer special-cased (messages without a roomid now
always get sent to console rather than lobby)
- A new challenge API (#8303)
- A new system for specifying battle rules with numbers and other
options (#8267)
This introduces a new class, BattleActions, available as `battle.actions`,
moving all functions from `data/scripts.ts` to `sim/battle-actions.ts`.
This makes it so that "go to definition" will now work correctly for
functions previously in scripts; we no longer need UnimplementedError,
and there's now a clean conceptual separation between `battle` and
`battle-actions` (whereas the previous distinction between `battle` and
`scripts` was basically nonexistent).
This will be a difficult migration if you maintain a fork with custom
scripted mods. I'm sorry! Migration instructions are here:
https://github.com/smogon/pokemon-showdown/pull/8138
Building from a fresh install currently fails since #7797
The problem is that `require('sucrase')` needs to be done _after_
sucrase is installed, which is a lot harder than it sounds.
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.
We're skipping two major typescript-eslint versions, so there are a
bunch of changes here, including:
- it's catching a lot of things it didn't catch in the past, for
reasons unclear to me
- no-unused-vars has to be explicitly disabled in global-types now
- a lot of `ts-ignore`s were never necessary and have been fixed
- Crashlogger can now handle being thrown things that aren't errors.
This has never been a problem in the past, but to satisfy TypeScript
we might as well not die in a fire on the off chance someone tries to
`throw null` or something.
We were previously using `type Foo = import('bar').Foo` which works
actually equally well, because sucrase didn't support `import type`,
but now it does!
