Fix typescript build errors/warnings

[mischnic]

1. Parcel's type definition pipeline doesn't actually use tsconfig's "include", so the global module definiton in @react-types/shared/src/css.d.ts that defines a type for CSS modules imports is not loaded.
   I've added a triple-slash reference directive in @react-types/shared/src/index.d.ts so that every asset that somehow imports @react-types/shared gets the definition.
2. Added two missing library definitions from ES2017 for Object.keys and Intl.DateTimeFormatPartTypes:

@parcel/transformer-typescript-types: Property 'entries' does not exist on type 'ObjectConstructor'.
react-spectrum-v3/packages/@react-aria/i18n/src/useNumberFormatter.ts:24:45
  23 |   let {locale} = useLocale();
> 24 |   let cacheKey = locale + (options ? Object.entries(options).sort((a, b) => a[0] < b[0] ? -1 : 1).join() : '');
>    |                                             ^^^^^^^^ Property 'entries' does not exist on type 'ObjectConstructor'.
  25 |   if (formatterCache.has(cacheKey)) {
  26 |     return formatterCache.get(cacheKey);

3. @react-aria/visually-hidden also has a CSS import: I've added a reference comment that "imports" the types package to get the definition from 1. and sideEffects: ["*.css"]
4. Made the type for CSS modules imports actually meaningful (object type mapping string to string).

📝 Test Instructions:

make build: no errors/warnings
yarn tsc: no errors/warnings

[adobe-bot]

Build successful! 🎉

• View the storybook
• View the documentation

[devongovett]

What happens when the components get published? Does this end up being loaded in user apps?

[devongovett]

Parcel's type definition pipeline doesn't actually use tsconfig's "include"

should it? feels weird that running tsc passes, but running it through Parcel does not.

[mischnic]

The difference is that tsc processes all files specified by include/excludes but the types transformer uses the asset as the root and only processes imported files (it never sees the css.d.ts file because it isn't imported anywhere).
You mean the types transformer should essentially start up the full TSC project with all files on every asset? There would be no cache in that case

[devongovett]

Ah right. We're kinda compiling each package independently rather than the whole repo. Do we basically want the one asset as a root, plus the includes? Would be as if there was a tsconfig in each package specifying that.

Mostly I'm concerned that the triple slash directive would affect the code once it's published and potentially mess with css handling types that users have in their apps.

[mischnic]

Mostly I'm concerned that the triple slash directive would affect the code once it's published

That is indeed a problem:

• scoping the CSS declaration to the packages doesn't work because these TS wildcards are very limited
• a <reference path="css.d.ts" /> to a missing file throws an error, so not publishing css.d.ts doesn't work either.

Only way I can think of is adding <reference types="@react-types/css" /> to every single asset that has a CSS import (not utils), they do get removed in that case. This CSS package would contain the declare module '*.css' and would not get published.

Do we basically want the one asset as a root, plus the includes

Then TSC would still give us a declare module for every asset in the project and the types transformer could remove all of them via the existing tree shaking, but:

I did a quite test (the output has a few wrong reeports, but this is about performance...):

only asset as root (current approach):
 build --no-minify packages/@react-spectrum/alert --no-cache  31.93s user, 4.83s system∞ 229% cpu, 16.014 total
all files as root:
 build --no-minify packages/@react-spectrum/alert --no-cache  68.94s user, 6.75s system∞ 185% cpu, 40.913 total

building all packages (current approach): 
make build  561.77s user, 62.61s system, 502% cpu, 2:04.15 total

So I'd say this is not an option unless you want to take builds 2,5 times longer or we instead create a single TS program and emit all declaration files at once.
Furthermore, caching would be useless because building a single package now depends on every other file in the whole project.

[devongovett]

Should there be a tsconfig in every package with include: ["src/index.ts", "/path/to/css.d.ts"] or something? 😬 That would be kinda annoying.

create a single TS program and emit all declaration files at once

That sounds nice, but kinda hard to do in Parcel's architecture. Probably would avoid TS reparsing a bunch of files though. Not sure if possible anyway - I think outFile would want to bundle them all together into a single file, not per package.

[mischnic]

Should there be a tsconfig in every package with

The types transformer still wouldn't use the includes

• So far the only solution I found is adding a /// <reference types="css-module-types" /> into every file that imports CSS. The comment gets removed by the types transformer. (I've commited this for now)

• Or adding @ts-ignore to every css import

• (Look away when Parcel prints TS errors)

but kinda hard to do in Parcel's architecture

Indeed

I think outFile would want to bundle them all together into a single file, not per package.

If we do want to do that (this would essentially be just a Node script, not inside Parcel), I was thinking of:

1. Generate a declaration file for the whole project (with individual declare module "...")
2. Process (shake) that file once per package (so every output bundle) to remove the declarations of the other packages.

[adobe-bot]

Build successful! 🎉

• View the storybook
• View the documentation

[adobe-bot]

Build successful! 🎉

• View the storybook
• View the documentation

[adobe-bot]

Build successful! 🎉

• View the storybook
• View the documentation

[adobe-bot]

Build successful! 🎉

• View the storybook
• View the documentation