Split types into their own imports / exports

[sgomes]

There are currently a number of warnings in the build process, related to how composite-checkout is importing and exporting TypeScript types.

This PR fixes that, by importing and exporting types separately from actual JS constructs.

It also prevents a JS file from attempting to export TS types.

Note that this PR includes a temporary directive to disable an ESLint rule, because of an ongoing bug in its plugin (eslint-plugin-import) with TS 3.8 (see this bug).

Changes proposed in this Pull Request

• Split types into their own imports / exports

Testing instructions

• Build calypso locally
• Ensure all the warnings about missing exports in composite-checkout are gone.
• Ensure composite-checkout/wpcom-related functionality still works?

This PR mostly fixes #41113, with one warning (in an external package) remaining.

[matticbot]

Test live: https://calypso.live/?branch=fix/composite-checkout-import-bugs

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~109 bytes removed 📉 [gzipped])

name      parsed_size           gzip_size
checkout       -404 B  (-0.0%)     -109 B  (-0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory.
Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[sirbrillig]

Looks good to me! Tested composite checkout and nothing appears broken.

Thank you for doing this!

[sirreal]

Should we explore the importsNotUsedAsValues compiler option? (set to "error")

Specify emit/checking behavior for imports that are only used for
types. "remove" and "preserve" specify whether to emit unused imports for side effects,
and "error" enforces that imports used only for types are written with import type.

I've been reluctant to start using type imports because I'd read that it will mostly be unnecessary, however I believe that's true with the TypeScript compiler (tsc), but not so with the babel compiler we're currently using. In cases where we import both types and values, do we still get warnings?

[sgomes]

In cases where we import both types and values, do we still get warnings?

@sirreal It isn't clear to me whether the errors this PR is trying to fix are caused by mixed imports or mixed exports. One error that is clear, however, is that there is a JS file trying to export TS types, which shouldn't happen.

Now, the reason I opted for separating things into import and import type (as well as export and export type) is for a matter of clarity. It makes it immediately obvious what is a type and what isn't, which helps prevent errors like the JS file trying to export types.

If a TS file exports both types and JS constructs with the same export statement, it isn't immediately obvious what a JS file can safely consume and re-export, particularly if those are already re-exports in the TS file, as was the case here!

For those reasons, I would vote for always keeping types and JS constructs separate, in their own imports/exports.

[sirreal]

I would vote for always keeping types and JS constructs separate.

I'm OK with trying this direction.