feat(experience): experience support old browser

[msmarks]

Summary

This PR is relative to https://github.com/logto-io/logto/issues/3878 ， https://github.com/logto-io/logto/issues/3059 Current Parcel config use

• Object: fromEntries ( support by chrome >=73 )
• Optional chaining operator ( support by chrome >= 80 ) cover 69.72% of Chinese people.

Since described in Parcel does not include polyfill for older browsers even when browserslist is declared in the package.json

• Parcel only transpiles the code according to the browserslist but doesn't handle runtime polyfills.
• Parcel always pass mode: entry to swc, and SWC treats it similarly to useBuiltIns: entry in Babel.

This PR add core-js to the entry of the experience package, and SWC will include the required parts of it for the browserslist.

The Browserslist in package.json is also updated to support as many users as possible for login, as it uses ReadableStream in the get-stream node modules. chrome 52 is the earliest version support it. So We choose chrome 52 as start point. Current Browserslist will cover 97.1 % global user.

Such configuration in Parcel will output two JavaScript files. One of them, based on the aforementioned Browserslist, excludes versions of browsers that do not support ES module features. This is referred to as the 'modern' version, primarily including versions of Chrome greater than 61. The other file is the 'compatibility' version. The browser will automatically choose which version to load.

Testing

Checklist

• [ ] .changeset
• [ ] unit tests
• [ ] integration tests
• [ ] necessary TSDoc comments

[github-actions[bot]]

COMPARE TO master

Total Size Diff :chart_with_upwards_trend: +358 Bytes

Diff by File

Name	Diff
packages/experience/package.json	:chart_with_upwards_trend: +223 Bytes
packages/experience/src/index.tsx	:chart_with_upwards_trend: +84 Bytes
pnpm-lock.yaml	:chart_with_upwards_trend: +51 Bytes

[simeng-li]

Hi @msmarks Thank you for your input. Rather than directly modifying the default build settings, we prefer to offer a separate build script or make it controllable via an additional argument in the build script. This ensures that it doesn't alter Logto's default build process, especially when it involves additional polyfill libraries.
For developers who specifically require legacy browser support. Implementing an on-demand build for the corresponding legacy version would be ideal.

[msmarks]

Hi @simeng-li Thank you for quick reply. However, I'd like to understand why you don't want to directly modify the default configuration. Using the 'defaults' configuration, the coverage in both China and the United States is below 80%. The login page is the gateway to the website and should support as many browsers as possible. I've been compiling logto using the aforementioned configuration for over half a year now. Is it possible for the official team to maintain a Docker image branch that supports older versions of browsers?

[simeng-li]

We had a brief discussion on this internally, sounds doable. Would like to double-check the output package size. Let's rollout this PR first. Thanks again for the contribution.

[msmarks]

@simeng-li Thank you for considering this matter. It would make me very happy to be able to contribute. Please allow me some time (after I finish work) to complete the tasks mentioned above. As for the transmission part, I have some approximate data: after gzip compression, the data increased by 34KB

[xiaoyijun]

Hi @msmarks , Thank you for your PR! Regarding the loading question, I'd like to confirm: are the corresponding JS files downloaded on demand from the remote server, or they're all downloaded upfront, and the browser executing them selectively as needed?

[msmarks]

Hi @msmarks , Thank you for your PR! Regarding the loading question, I'd like to confirm: are the corresponding JS files downloaded on demand from the remote server, or they're all downloaded upfront, and the browser executing them selectively as needed?

It use the techniques discussed in Phillip Walton's excellent post

Simply put, it simultaneously uses

<script type="module" src="xxxx. js">

and

<script nomodule src="yyyy. js">

The former's older browsers do not recognize scripts of type="module" and will refuse to load them

The latter's new browser knows nomodule and will choose not to load it

[simeng-li]

@msmarks I just found a minor issue in a failed ci job script. Do you mind rebasing the latest Logto master branch and trying again? This will give the green light on all the ci jobs. Thx

[msmarks]

@msmarks I just found a minor issue in a failed ci job script. Do you mind rebasing the latest Logto master branch and trying again? This will give the green light on all the ci jobs. Thx

It was rebased.

[xiaoyijun]

Hi @msmarks , one last thing: our repo requires that every commit must be signed. Could you please sign your commits so that we can merge this PR?

Refer to: Learn more about signing commits

[msmarks]

Hi @msmarks , one last thing: our repo requires that every commit must be signed. Could you please sign your commits so that we can merge this PR?

Refer to: [Learn more about signing commits](https://docs.github.com/articles/about-gpg/)

sure, signed.

[xiaoyijun]

Thanks @msmarks !