POC: Emit TS errors as warnings

[rrennick]

Changes proposed in this Pull Request:

This is a proof of concept for easing TS compiler strictness to allow updating our packages to use wp-6.4. It uses babel to build the output files if the TS build fails.

See #45535 .

How to test the changes in this Pull Request:

Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:

1. Run pnpm build:project:cjs
2. Run pnpm build:project:esm
3. Run watches of both

Changelog entry

• Automatically create a changelog entry from the details below.

Significance

• Patch
• Minor
• Major

Type

• Fix - Fixes an existing bug
• Add - Adds functionality
• Update - Update existing functionality
• Dev - Development related task
• Tweak - A minor adjustment to the codebase
• Performance - Address performance issues
• Enhancement - Improvement to existing functionality

Message

Comment

[rrennick]

I did not implement tsc --noEmit because this would stop generating the build files if no TS errors occurred.

[samueljseay]

@rrennick I think I made a mistake in my initial analysis because the libraries need to emit build types that each other library uses 😭 and only TS can generate those. I'm sorry I don't know why I didn't think of that at the time.

I think we can only use type checking approach in consuming packages such as blocks, admin, product editor, basically anywhere we use a webpack config. In those projects we can use something like https://github.com/TypeStrong/fork-ts-checker-webpack-plugin but not have it block building.

I still think it would generously help the situation because we'd only be limited to fixing problems in the library packages themselves not in the downstream projects that consume them. If there is a type change due to dependency update, teams will have time to fix them instead of it immediately breaking their builds

[rrennick]

I think I made a mistake in my initial analysis because the libraries need to emit build types that each other library uses 😭 and only TS can generate those.

I thought it would be worth a try to add tsc --emitDeclarationOnly before adding another dependency. This seems to work okay from my testing. The CI build fails on the components package. Does this mean we would need to make these changes to all of the packages in the same PR?

[samueljseay]

@rrennick if we do it in this direction where we start with the packages everything depends on then yes there is a good chance we'll break all consuming packages.

Before what we tried was basically both directions: we fix all the type issues in the packages, then all the consumers break because the types are different so we fix those as well (all within the same gigantic PR). My rough idea here that supposedly cuts the work in half is to have type errors on build in consuming packages be turned into warnings, then fix all the types in one package at a time (although this will cause some cascading type issues in some cases like data package may now break components like you're encountering) but in theory it reduces the workload to just fixing types within the packages.

Please let me know if you'd like any help or support with this, we could probably work together on it.

[samueljseay]

ts-loader has transpileOnly setting and combined with https://github.com/TypeStrong/fork-ts-checker-webpack-plugin it will still check and report errors during development but not block building

[rrennick]

it will still check and report errors during development but not block building

@samueljseay I'll have a look at it tomorrow.

Please let me know if you'd like any help or support with this, we could probably work together on it.

That sounds great. Once we have the POC working the way we want then we can plan the larger project.

[rrennick]

it will still check and report errors during development but not block building

@samueljseay I wasn't able to get build output with the transpileOnly option (only updated the build:project:esm command to webpack). I've pushed my last iteration of config changes.

[samueljseay]

@rrennick you're not supposed to get build output from transpile only. and build:project:esm belongs to packages. maybe you misunderstood what I'm suggesting here.

I'm suggesting leaving type checking and build as normal in the packages that don't have a webpack.config already

then in existing webpack builds like woocommerce-admin or product-editor (any package with webpack.config.js) using the https://github.com/TypeStrong/fork-ts-checker-webpack-plugin to do type checking / reporting but not fail because it won't actually compile the TS only check it. This would mean we still have to fix type issues in packages but not in product editor or wc-admin for example

[rrennick]

Do we need two configuration files for babel?

[rrennick]

I'm not sure why this line keeps getting removed when I run pnpm i. We should restore this line.

[samueljseay]

@rrennick dependencyOutputs is auto generated by the .pnpmfile.cjs if it's removing this there may be a bug there to investigate.