ExPlat: Loosen requirements on dependencies

[jessie-ross]

Changes proposed in this Pull Request

• Loosen the requirements of dependencies

See: 12687-gh-Automattic/woocommerce.com#issuecomment-1106673768

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-31922

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-31922&env=jetpack

[jessie-ross]

Hmm, tests are failing, seems like this isn't working like I thought...

[andfinally]

Thanks! I'm not sure how to test the package with WCCOM's version, but I'm confident this will do the trick!

[matticbot]

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

App Entrypoints (~95 bytes added 📈 [gzipped])

name                 parsed_size           gzip_size
entry-gutenboarding       +337 B  (+0.0%)      +95 B  (+0.0%)

Common code that is always downloaded and parsed every time the app is loaded, no matter which route is used.

Sections (~20 bytes removed 📉 [gzipped])

name                   parsed_size           gzip_size
signup                       -21 B  (-0.0%)       -4 B  (-0.0%)
plans                        -21 B  (-0.0%)       -2 B  (-0.0%)
pages                        -21 B  (-0.0%)       -3 B  (-0.0%)
jetpack-connect              -21 B  (-0.0%)       -3 B  (-0.0%)
jetpack-cloud-pricing        -21 B  (-0.0%)       -4 B  (-0.0%)
checkout                     -21 B  (-0.0%)       -8 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.

Async-loaded Components (~96 bytes added 📈 [gzipped])

name                                             parsed_size           gzip_size
async-load-block-editor                               +337 B  (+0.0%)     +100 B  (+0.0%)
async-load-signup-steps-plans                          -21 B  (-0.0%)       -4 B  (-0.0%)
async-load-signup-steps-domains                        -21 B  (-0.0%)       -4 B  (-0.0%)
async-load-plan-upsell                                 -21 B  (-0.0%)       -4 B  (-0.0%)
async-load-calypso-my-sites-checkout-modal             -21 B  (-0.0%)       -4 B  (-0.0%)
async-load-calypso-blocks-editor-checkout-modal        -21 B  (-0.0%)       -4 B  (-0.0%)
async-load-calypso-blocks-app-banner                   -21 B  (-0.0%)       -4 B  (-0.0%)

React components that are loaded lazily, when a certain part of UI is displayed for the first time.

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.

[jsnajdr]

The yarn.lock file introduces some unwanted duplications that can be easily resolved by merging them into existing resolution. I pointed out a few examples, there are a few more.

[jessie-ross]

@testing-library/react-hooks doesn't yet support React 18:
testing-library/react-hooks-testing-library#654

[jessie-ross]

WCCom seems to use 16.14 so we should be good here.

[jsnajdr]

Also, is there a reason why React 18 should be excluded? The Explat bindings should work with v18 equally well as with an earlier v16 or v17, shouldn't they?

[jessie-ross]

Unfortunately @testing-library/react-hooks doesn't yet support React 18:
testing-library/react-hooks-testing-library#654

My unit tests are getting errors where I try to use it because the testing-library is incompatible with React 18.

[andfinally]

Nice... thanks!

I'm not sure how to tell what React version WCCOM is running – we're currently on WordPress 5.9.3, which seems to use React 17.0.1.

I assume this change will eventually make its way into https://www.npmjs.com/package/@automattic/explat-client-react-helpers, from where I can try it in WCCOM.

[jessie-ross]

@andfinally

I've now published this to NPM so you can try it out :)

[andfinally]

Thanks @jessie-ross, I'm getting a rather baffling error from the package. When I add

"@automattic/explat-client-react-helpers": "0.0.5"

to our dependencies and install, then import createExPlatClientReactHelpers as

import createExPlatClientReactHelpers from '@automattic/explat-client-react-helpers';

and create the helpers as before, I get this in the browser:

Uncaught Error: Module parse failed: Unexpected token (46:39)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
|             return _jsx(_Fragment, { children: loadingExperience });
|         }
>         else if (!experimentAssignment?.variationName) {
|             return _jsx(_Fragment, { children: defaultExperience });
|         }
    node_modules components.min.js:109

[jessie-ross]

@andfinally it looks like it is choking on the optional chaining (character 39), after all the packages have been built and minified by WCCom's build tool. Might be something to do with the targeting of TypeScript compilation in WCCom. Is there anyone experienced with WCCom's JS build setup we could ask?

[jessie-ross]

This has changed actually:
https://github.com/Automattic/wp-calypso/pull/62979/files#diff-3fd3d0fd4911baf7bc740d55e06560d1e192fcaac13acb26cba6bf2c4bbf3494L30

It might be worth a try specifying "tslib": "^2.3.0" in WCCom's package.json.

[andfinally]

Thanks Jessie! Unfortunately tslib hasn't done the trick. I don't think we have any TS compilation, because we have no TS. Let me throw it open to the gang to see if anybody has any bright ideas.

[jsnajdr]

Uncaught Error: Module parse failed: Unexpected token (46:39)

This error is thrown by webpack. After a JS/TS source file is processed and transpiled by Babel or the TypeScript compiler (invoked inside a webpack loader), the loader-processed source file goes to webpack that further processes it for bundling. And here webpack parses it with the Acorn parser. Apparently the version of the Acorn parser used by webpack doesn't know the ?. syntax yet, most likely because it's some older version.

The issue is that the @automattic/explat-client-react-helpers package, as published in NPM, ships the ?. syntax without transpiling it for older browsers. All Calypso-managed packages do that. And the WC.com build process itself doesn't transpile files imported from node_modules either. Which it probably should do, because I assume the WC.com site should run also on older browsers.

The issue has nothing to do with TypeScript or tslib.