Split Temporal polyfill components

[fgarcia]

Currently using this polyfill takes 53.8kB (gzip, v0.4.3)

I know we are not supposed to use this in production, that is the reason I already have some self baked equivalents to Duration and PlainDate.

While trying to future proof my implementation by making the interface/api closer to the one in Temporal, I want to replace parts of the existing code with the one used in the polyfill. Hopefully after Stage 4 I will be able to drop lots of code, but in the meantime, it would have to write less temporal code if I could import just the parts I need.

[12wrigja]

You are envisioning something like

import {Duration} from '@js-temporal/polyfill';

?

I don't think this will work very well because all of the cyclic dependencies between Temporal classes - if you called one of the methods to transform from one class type to the other (e.g. toZonedDateTime, toPlainDate, etc) those would fail because they can't construct the relevant class you'd be requesting.

Are you using the ES Module outputs we publish in your builds, and are you using an optimizer / bundler that can remove unused imports?

[fgarcia]

Actually I was aiming for something like this

import {Duration} from '@js-temporal/polyfill/Duration';

that should also be CommonJS friendlier, but as you said, with the inter dependencies between Temporal classes, the benefits will not be great. I have no idea how far a bundle optimizer would fix because I was counting on not depending on that. In the meantime I will try not to deviate from the Temporal API and have some clean drop-in-replacement once Temporal hits Stage 4

I will close this issue for now. Since Temporal is intended to become a standard, there is less value on optimizing the bundle size.

[ptomato]

It seems like if we wanted to make it possible to bundle smaller parts of the proposal, we'd have to make it so that e.g. PlainDate arithmetic methods (add, subtract, until, since) were bundled separately and would depend on both Duration and PlainDate being imported.

[12wrigja]

a bundle optimizer would fix because I was counting on not depending on it.

I don't understand why you would care about code-size and not be using a bundle optimizer?

I think the current structure of the polyfill (import {Temporal} from) is likely what is "saving" us from a large tree-shaking headache as mentioned above. If instead you could write import {ZonedDateTime} from '@js-temporal/polyfill' and then run <zonedDateTimeInstance>.toPlainDate() it would likely fail because there's no hard dependency between the plaindate.ts and zoneddatetime.ts files via ES Module identifiers, and so plaindate.ts would never be loaded / would be tree-shaken away.

[fgarcia]

@ptomato One perfect example would be a functional style like date-fns which is great to control bundle size. However I still find easier to explore/navigate libraries with a more classy object oriented. I quite like Temporal being the later, specially because once it becomes native, the bundling problem goes away.

I don't understand why you would care about code-size and not be using a bundle optimizer?

@12wrigja Sadly I still have to work with CommonJS based projects where tree shaking does not work so well (and I do not have the authority to change that). In those cases it works better having multiple exports. Also I deal very often with internal infrastructure scripts that tend to get large. Devops scripts that tend to run in development mode (no build process) do not feel very snappy because they start loading lots of extra code that has not been trimmed by a pre-build step.

After realizing how interconnected all classes in Temporal might be, I thought it would be unfair to request more modularity until I do more research, like investigating how much tree shaking can optimize things.