Stop overwriting native implementation while loading the polyfill

[fabon-f]

For now, importing the polyfill globally via temporal-polyfill/global overwrites globalThis.Temporal and other APIs.

https://github.com/fullcalendar/temporal-polyfill/blob/bc1baf3875392ecd8522d40e7eecb55fa582808c/packages/temporal-polyfill/src/global.ts

As Firefox will ship Temporal in next month and this polyfill follows latest stable spec, it would be better that the polyfill doesn't overwrite native implementation if exists.

https://groups.google.com/a/mozilla.org/g/dev-platform/c/RtsRo93ygO4/m/2YzM42GUBwAJ

Perhaps it's still early to do that, because the spec for non-ISO calendars (Intl era and monthCode Proposal) is in progress and not yet stable. It depends on which level of spec-compliance this polyfill targets on, I think.

[agavrilov]

FYI: Firefox 139.0 shipped with Temporal implementation enabled by default. See here: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/139

[Patronics]

I'd also be interested in an official way to enable the polyfill to only take effect when necessary, preventing overwriting the browser's Temporal implementation, at least as an optional configuration. It would also be interesting to see some performance benchmarks, demonstrating how the polyfilled implementation's performance compares to that of Firefox's native support (and to that of the other temporal Polyfill API(s)).

[DASPRiD]

I think for now you could do this, assuming you are using ESM:

if (typeof Temporal === "undefined") {
    await import("temporal-polyfill/global");
}

[arshaw]

I agree, it'd be nice to use the global Temporal of present, however, I think I want to wait until the champion-built @js-temporal/polyfill project decide to do the same:

tc39/proposal-temporal#778
js-temporal/temporal-polyfill#2

While the Temporal spec seems pretty stable, and Firefox has shipped, some details around week numbers, month codes, and option parsing are still being ironed out.