build(all): use typescript project references

[unstubbable]

This also enables skipLibCheck which reduces the compile time significantly. It is also a recommended compiler option.

Note: Explicit usage of third-party code is still checked.

• switch some scripts in packages/demos to js to avoid using ts-node (no support for project references)
• fix TypeDoc integration
• investigate change in size-limit result
  The increase of @feature-hub/core by 2 kb is caused by a newer version of semver (required by ts-loader) which introduced memoization to improve the performance of range parsing. With this lru-cache was added as a dependency which unfortunately leads to the larger overall size of @feature-hub/core.
• investigate why Netlify can not build the API docs

[fahrradflucht]

I don't understand why they recommend this option - isn't it just unsafe? You don't know anymore for example if your dep references browser APIs that aren't in your matrix or anything like that.

[unstubbable]

The code you are using is type checked. So if a browser API in these code paths is used that you don't support the compiler should be able to catch that (need to test that in a small repro). Of course this assumes that the lib itself would be free of side effects.

[fahrradflucht]

💡 I didn't know that. So what you are saying is this?

// node_modules/a/index.ts
function foo(): string {
  return new Intl.PluralRules().select(0);
}

function bar(): string {
  return "other";

// src/works.ts
import { bar } from "a";

console.log(bar());

// src/broken.ts
import { foo } from "a";

console.log(foo());

[unstubbable]

@fahrradflucht It's a good thing you started this discussion. Based on your example I created this test repo: https://github.com/unstubbable/skip-lib-check-test Quoting the README from there:

The documentation says:

TypeScript will type check the code you specifically refer to in your app’s source code.

What it does not mention, but should not be surprising now that I think about it, is that any library code that can not be compiled, but your app's source code refers to, will be regarded as any. Even with noImplicitAny set to true this does not yield a compile error.

This brings me to the conclusion that this compiler option should only be used a stop-gap measure (if at all) for a short period of time, when the types of two libraries (in this case webpack and @types/webpack-dev-middleware) are incompatible with each other.

[unstubbable]

Removed skipLibCheck again in 5e6161b. There is currently no issue without skipLibCheck, until we decide to update to webpack 5, and DefinitelyTyped/DefinitelyTyped#50773 is not resolved till then.

[unstubbable]

Interesting, with skipLibCheck removed, TypeDoc fails to generate the API docs with FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory somewhere in node_modules/typescript/lib/typescript.js. 🙄 EDIT: Seems to be a common issue: TypeStrong/typedoc#1346