coreutils and post-ES2018 Intl API features

[Renegade334]

Description

Since the removal of the moment library in #13469, the Time functions in coreutils now depend on the ECMA-402 internationalization APIs, namely DateTimeFormat and RelativeTimeFormat. As spotted recently when changes were made to time.ts in #15948, this starts to run into ES2018 compatibility issues.

In fact, RelativeTimeFormat doesn't exist at all under ES2018, nor do the dateStyle and timeStyle options passed to DateTimeFormat. The reason those features currently don't cause build errors is due to "types": ["node"] in the coreutils tsconfig, which as a side-effect pulls in the es2020.intl library definitions via the triple-slash directives at the top of index.d.ts in @types/node, suppressing the errors that would appear otherwise.

In addition, DateTimeFormat's dateStyle and timeStyle options were actually only added in the ES2021 standard, and there is a current proposal for these to be moved to the es2021.intl library accordingly. If and when this happens, those properties will no longer be defined in es2020.intl, and the coreutils build will subsequently break.

Expected behavior

If the decision is that JupyterLab should continue to use these post-ES2018 features, then the coreutils tsconfig should probably explicitly add the es2020.intl library to make this intention clear (and potentially es2021.intl to pre-empt the above), and/or implement a polyfill for users running on true ES2018 environments.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[jtpio]

Thanks @Renegade334 for the report 👍

If the decision is that JupyterLab should continue to use these post-ES2018 features

Yes, these features are likely to stay.

As spotted recently when changes were made to time.ts in #15948,

Looks like there were some discussions about this in this comment: #15948 (review), with the suggestion of bumping to ES2020 here:

jupyterlab/tsconfigbase.json

Line 19 in 8a17ca6

"target": "ES2018",

Not sure this could go in the 4.2 release, but probably in 4.3. Would you like to open a (draft) PR to start looking into it? Thanks!

[Renegade334]

Sounds good. 👍

Looks like there were some discussions about this in this comment: #15948 (review), with the suggestion of bumping to ES2020 here:

jupyterlab/tsconfigbase.json

Line 19 in 8a17ca6

"target": "ES2018",

I assume this refers to bumping "lib" rather than the build target?

[JasonWeill]

@Renegade334 Thank you for opening this! I had previously tried upgrading the library locally, but I ran into other compatibility issues. I appreciate you working on this.