Commit Graph

4 Commits

Author SHA1 Message Date
Jack Franklin
ae7483d5cf
chore: remove src/externs.d.ts (#5811)
* chore: remove src/externs.d.ts

It defined global types that we don't want to use, and instead we move
to using interfaces that we import and reference just like with any
other interface.

This means other than Protocol (which I think is fine to leave as is),
there are no other magic global types and you have to import any types
or interfaces that you want.
2020-05-06 14:23:07 +01:00
Jack Franklin
ec91ecaf0b
chore: migrate src/Launcher to TypeScript (#5775) 2020-04-30 13:45:58 +01:00
Jack Franklin
3600f2f99b
chore: migrate src/helpers.ts to ESM (#5699)
* chore: migrate src/helpers.ts to ESM

Doing this means we can avoid the global `types.d.ts` file and export
the interface via ESM instead.

I would ideally like to rewrite the helper module so that it doesn't
export all the functions under the `helper` namespace, but I'll leave
that for a separate PR to keep mechanical changes to one per PR and
easier to review.
2020-04-21 10:22:20 +01:00
Jack Franklin
e7a32a8851
chore: migrate src/pipetransport to typescript (#5692)
* chore: migrate `src/pipetransport` to typescript

Hit one bump in the fact that I want to share an interface across files.
TypeScript only lets you import/export these if you're using ESM, not
CommonJS. So the two options are:

- Migrate to ESM on a per file basis as we do this migration. This won't
affect the output as we output as CommonJS.
- Create a global `types.d.ts` file that we'll use and then migrate to
ESM after.

Right now I've gone for the second option in order to not introduce more
changes in one go. But if we end up finding we have lots of
interfaces/types/etc that we want modules to expose, we might decide
slowly introducing ESM might be a better way forwards.

* Update src/types.d.ts

Co-Authored-By: Mathias Bynens <mathias@qiwi.be>
2020-04-20 15:05:58 +01:00