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.
The problem is that we were cleaning up old REPL sockets after
launching new ones. This moves the cleanup step to before Artemis
and Friends processes are launched.
`./build decl` now builds TS declarations for everything exported by
`sim/`. Unfortunately, the built TS declarations still refer to global
types, so some things still have `any` type, but it's much better than
nothing.
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.
For some reason, my last try failed. The error just wasn't getting
caught. This is an attempt to make it not listen to the `'close'` event
if the `listen` function throws, which might work? I'll reboot to test
in Windows when I have time.
Refs #6873
`import =` and `export =` are really only intended for backwards
compatibility with CommonJS. While I really don't like the new module
system TC39 has designed for us, it's what we should be using, and
consistency is important.
