I'm currently pretty annoyed at TypeScript and TC39 for default exports
being a mess.
The goal here is to be able to type
import Dex from './dex';
instead of any of
import Dex = require('./dex');
import {Dex} from './dex';
import * as Dex from './dex';
This part involves a significant amount of struggle.
First, you can't automatically package up all your exports as your
default export. This leads to extremely un-DRY code, like in sim/index:
export {
Pokemon,
Side,
Battle,
PRNG,
Dex,
TeamValidator,
BattleStream,
};
export const Sim = {
Pokemon,
Side,
Battle,
PRNG,
Dex,
TeamValidator,
BattleStream,
};
(Both of these exports would be entirely unnecessary if you could just
automatically declare the file's exports as a default namespace.)
Second, a default export can't easily be a namespace. And TypeScript
doesn't allow types to exist in objects. Take the example from earlier:
export const Sim = {
Pokemon,
};
If we were to try to use it:
import Sim from './sim';
let pokemon: Sim.Pokemon;
you'll get this error:
Cannot find namespace 'Sim'. ts(2503)
You can, of course, fix this by making Sim a namespace:
const PokemonT = Pokemon;
type PokemonT = Pokemon;
export namespace Sim {
export const Pokemon = PokemonT;
type Pokemon = PokemonT;
}
But this quickly gets ridiculous the more classes you try to export.
You'd think there'd be a better way to do this. But I, at least,
haven't found one.
They were previously some weird interface where their actual types
were properties. I guess whoever wrote this was unaware that TypeScript
namespaces were designed for this exact use-case.
This is actually three refactors:
- swap around thing:slot for slot:thing in MoveHitData
- add Pokemon#getSlot
- remove the ActiveMove class; it's back to being an interface
See #5415 for context - having these methods is unsafe and leads
to crashes because not all ActiveMoves are created through the
Data.ActiveMove constructor. Instead of Pokemon, these could
alternatively be static methods on ActiveMove (or the ActiveMove
class could be completely abolished and reverted back to an
interface), but #5415 will deal with ActiveMove long term, this just
fixes the crashes.
`default` papers over AI logic errors. This change fixes those
errors instead:
- handle maybeDisabled/maybeTrapped properly
- use 0 PP and ally-less 'adjacentAlly' moves if necessary.
