Proposal-temporal: Publish polyfill to npm registry?

[ljqx]

Any plan to publish polyfill to npm or merge it into core-js?
Couldn't wait to use it :)

There is already discussion in core-js to implement polyfill for this proposal.

I've wrapped existing polyfill (actually it's ponyfill) and published it to https://www.npmjs.com/package/tc39-proposal-temporal. For easing the adoption, I've Babeled the final index.js.

But it's great if we can have an official package.

Please let me know if you want take this name over.

[pipobscure]

Hi all, we have every intention to publish the polyfill to npm and make it available. Right now we are waiting to stabilize the spec a bit more, which I foresee happening this summer.

[pipobscure]

(So yes I'd very much like to publish it as temporal)

[ljharb]

The polyfill should also be extracted and removed from the proposal repo first.

[littledan]

@ljharb I'd like to understand your request here. Are you saying the polyfill needs to be developed in a separate repository from the proposal? If so, why? We've specifically discussed this issue in a past Date meeting, and didn't see a reason why it needed to be developed separately.

[ljharb]

This has come up before in a TC39 meeting (possibly in a hallway) and the belief was that the committee shouldn’t be in the business of providing actual implementations - linking to one, or providing an example non-production one in the proposal repo, being exceptions.

I don’t believe that there’s any other examples of a proposal repo hosting the code for a published polyfill besides this one and possibly Realms - ie, this is not something with precedent.

[littledan]

I still don't quite get it. If proposal champions work on a polyfill, why should it not be in the same repository as the proposal? What purpose does using a separate repository serve?

There is definitely precedent here, for example in simd.js. Maybe that doesn't count, as it is not a useful or complete polyfill, though.

[ljharb]

SIMD indeed does not count, for the reasons you outlined - it's in the category of "an example non-production polyfill", which does belong in a proposal repo.

The separate repository would not be part of the tc39 org, nor would be under tc39's purview - the fact that the champions might be the primary maintainers of it doesn't mean tc39 has to, or should, own production-usable code.

Separately, a concern is that it would be tc39 "blessing" a particular implementation. In the case of polyfills, if someone produced an alternative Temporal polyfill, nobody would use it over the "official TC39" polyfill - whereas if this one was in a separate repo, it gives the ecosystem a fair chance to compete.

[pipobscure]

A TC39 meeting just happend. There are a few issues that we have to debate and come to conclusions. As soon as we have those ironed out, I'll do an initial PR to https://github.com/zloirock/core-js/issues/365

(I'm expecting this to happend toward the end of August 2018 in a first iteration)

[ljharb]

Feel free to PR into core-js, but I’d really like to see a standalone npm package, and would be forced to create one myself if the only other place it lived was core-js.

[pipobscure]

Oh, I thought core-js was the preferred place.

In this case I’ll definitely create a separate package first.

On 27 Jul 2018, at 17:13, Jordan Harband [e-mail] wrote:

Feel free to PR into core-js, but I’d really like to see a standalone npm package, and would be forced to create one myself if the only other place it lived was core-js.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[littledan]

I like the idea of a separate package.

I still don't see the problem with the champions developing and blessing a particular polyfill in this case. How about we develop this advice as part of the how-we-work effort, and continue the discussion there?

[pipobscure]

I noticed that the polyfill was published a few times already:

• @wealthbar/tc39-temporal by @chrisnicola, @tanglebones, @thejf, @pezillionaire
• tc39-proposal-temporal by @ljqx

I'd really like to unite these efforts. Plus it seems that this is so highly desired that people decided to go ahead and publish without even telling anyone they'd do that, which tells me it may be time to actually publish this now.

@ljqx can you add me as a collaborator and we'll use that as the canonical publish. The wealthbar scoped version will just remain as is and if they want to deprecate it in favour of the canonical they can.

[ljqx]

@pipobscure , have added you as an owner. I'd made several changes to make it directly usable in non-modern browsers (IE 11 specifically). Feel free to override it with the official one.

And what's the plan with name temporal?

[pipobscure]

Thanks!
I’ll try to incorporate your backwards compat changes. And fix the repo url, etc.

Re the name: temporal is already taken by some queuing library. So I was looking for a name to publish under. Anyone habe any strong feelings?

On 4 Aug 2018, at 13:14, Remi Liu [e-mail] wrote:

@pipobscure , have added you as an owner. I'd made several changes to make it directly usable in non-modern browsers (IE 11 specifically). Feel free to override it with the official one.

And what's the plan with name temporal?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[gibson042]

The polyfill is now at https://github.com/std-proposal/temporal and any issues regarding its publication should be opened there.

[felixfbecker]

The polyfills in this repo and https://github.com/std-proposal/temporal seem to be incompatible and the npm packages are all out of date. What is the recommended, latest package to use?

[ryzokuken]

I think you should use the polyfill in the current repo if needed since it's the best source of truth wrt the proposal. However, it is still under active development so I'd take that advice with a grain of salt.

[littledan]

We should probably mark the other repo as inactive, or even archive it. We could also write a note visible from npm that that module is out of date, and pointing to current development. Ambiguity is not useful here.

[LinusU]

We should probably mark the other repo as inactive, or even archive it. We could also write a note visible from npm that that module is out of date, and pointing to current development.

Would very much appreciate if if both of these steps were taken! I've spent the last hour trying to find the "canonical" version to use.

From what I can gather, the current status is: None of the packages on Npm are up-to-date, the lastest polyfill code lives in this repository (tc39/proposal-temporal), and there are enough changes happening at the moment that people shouldn't use this in production now.

Is this a correct assessment? ☺️

[ljharb]

You shouldn’t use any feature in production prior to stage 3.

[ryzokuken]

@LinusU

None of the packages on Npm are up-to-date

Yes

the lastest polyfill code lives in this repository (tc39/proposal-temporal)

Yes

there are enough changes happening at the moment that people shouldn't use this in production now.

Yes

You shouldn’t use any feature in production prior to stage 3.

Couldn't be summed up better. That said, that doesn't mean that you should strictly stay away from this polyfill. If you'd like to play with it and give feedback, that'd be awesome!

[LinusU]

Thank you @ryzokuken, that's a perfect answer 👍

Hopefully I'll get some time to play with this and see if I can give some good feedback...