Stable 3.0 release?

[kylefox]

Hey, first off: thanks for the excellent library 🙂

I'm just wondering if there's plans for a stable 3.0 release. The beta was released two months ago and it doesn't seem like there's been much activity since then.

(FWIW, I experimented with v3.0.0-beta.0 in my application and it seems to work just fine)

Please let me know if there's anything I could possibly help with to get 3.0 released 👍

[nreynis]

I've got a couple more request to submit. One of them may be a breaking change for some narrow use cases, so if we could hold the release a little longer...

[carhartl]

Yes, we will...

[carhartl]

Hehe, yes we will... hold the release a little longer, and release a stable v3 :)

So there are some changes in the pipeline, and then there's going to be another beta, and at some point a stable release.

[carhartl]

Bumped the beta one more time... nearing the stable release (-> rc -> stable).

[FagnerMartinsBrack]

We still need a decision on this one.

We know it makes sense for a new converter API has to get in, then it's better to do it before final release. If not, then could we design the existing converter in a way we can extend later to add the converter for cookie name with a minor not major bump?

[carhartl]

There's a release candidate now:

npm i js-cookie@rc

[FagnerMartinsBrack]

Shall we keep for a few months instead of a few weeks just in case something big as the encoding comes up or do you believe that's too much?

[carhartl]

A few months sounds a bit too much to me.. at some point we should just release it or it will never happen. I‘m expecting a lot of issues coming in after we released anyway (because the encoding isn‘t compatible in v2 vs v3, which might surprise people who may not have read the release notes).

Would be useful to track the number of downloads of the rc in order to decide, as a rough estimate for usage..

[hartator]

because the encoding isn‘t compatible in v2 vs v3, which might surprise people who may not have read the release notes

Any reason why it doesn't have a default encoder that's the same behavior in v3 as in v2?

This will still allow custom encoders while being backward compatible and will work as expected by avoiding the %40-type that seems to be very common issues.

[carhartl]

Any reason why it doesn't have a default encoder that's the same behavior in v3 as in v2

Because the implementation in v2 was wrong and we don‘t want to port the mistake to the new version.

[hartator]

Any reason why it doesn't have a default encoder that's the same behavior in v3 as in v2

Because the implementation in v2 was wrong and we don‘t want to port the mistake to the new version.

Cookies should not be decoded using decodeURIComponent?

[carhartl]

Cookies should not be decoded using decodeURIComponent?

Not necessarily, it‘s common, but RFC 6265 doesn‘t demand anything like that. In fact it suggests to use base64 encoding for cookie values.

The reason we changed it in v3 is that we implemented the encoding following the guidelines for server inplementers (section 4) while we needed to follow section 5.2 (plus HTML 5 spec) which is less strict (to ensure interoperability). So we’re still using percent-encoding but for less characters. But we’re using percent-encoding because it works well/our own choosing.

[hartator]

Not necessarily, it‘s common, but RFC 6265 doesn‘t demand anything like that. In fact it suggests to use base64 encoding for cookie values.

The reason we changed it in v3 is that we implemented the encoding following the guidelines for server inplementers (section 4) while we needed to follow section 5.2 (plus HTML 5 spec) which is less strict (to ensure interoperability). So we’re still using percent-encoding but for less characters. But we’re using percent-encoding because it works well/our own choosing.

Got you. Thanks for the detailed answer. 👍

[lpellegr]

@carhartl Any updates?

[jubishop]

friendly ping on any updates to a 3.0 release :)

[carhartl]

For a 3.0 release we‘ll need to solve #595.

[kylefox]

Just wondering if #595 is still blocking a 3.0 stable release 🙂

It seems like discussion/development on #595 has stalled. Unless it's a regression from 2.x, could support for cookie names with brackets be a 3.x patch release?

[STR07]

Hey, are there any updates when 3.0 will be released? Thanks @carhartl

[FagnerMartinsBrack]

@STR07 I've commented on the last 2 issues we have pending (#595 and #646) which are apparently holding v3. Version 2 is pretty stable so I would advise using v2 in production instead of master for the time being as master changing all the time.

[mbolli]

@FagnerMartinsBrack my reason to use 3.x is that it's exposed as ES module.

[kylefox]

Version 2 is pretty stable so I would advise using v2 in production

@FagnerMartinsBrack As far as I can tell v2 does not support the sameSite parameter, does it?

I understand why #595 and #646 are important, but IMHO they seem less important that the ability to use ES6 modules and sameSite params. Could a "Converter API" (#595) and a no-conflict mode (#646) be introduced in a patch version, i.e. 3.1.0? Or maybe #595 is punted even farther to v4? Because otherwise it feels like v3 will be delayed indefinitely.

[FagnerMartinsBrack]

There are custom attributes in v2, are you able to use same-site there? Let me know if that doesn't work. There's nothing high priority pending for v3 that I'm aware.

On Sun, 2 May 2021 at 07:33, Kyle Fox ***@***.***> wrote: Version 2 is pretty stable so I would advise using v2 in production @FagnerMartinsBrack <https://github.com/FagnerMartinsBrack> As far as I can tell v2 does not support the sameSite parameter, does it? I understand why #595 <#595> and #646 <#646> are important, but IMHO they seem less important that the ability to use ES6 modules and sameSite params. Could a "Converter API" (#595 <#595>) and a no-conflict mode (#646 <#646>) be introduced in a patch version, i.e. 3.1.0? Or maybe #595 <#595> is punted even farther to v4? Because otherwise it feels like v3 will be delayed indefinitely. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGMCEKUQ7OPU5UGM6ZQLS3TLRXRZANCNFSM4JVNJUFA> .

-- <https://about.me/fagnerbrack?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links> Fagner Brack [image: https://]about.me/fagnerbrack <https://about.me/fagnerbrack?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>

[mbolli]

I understand why #595 and #646 are important, but IMHO they seem less important that the ability to use ES6 modules and sameSite params. Could a "Converter API" (#595) and a no-conflict mode (#646) be introduced in a patch version, i.e. 3.1.0? Or maybe #595 is punted even farther to v4? Because otherwise it feels like v3 will be delayed indefinitely.

@kylefox I second this. I'm all for a 3.0 release in the current state. It seems stable enough for what 99% of the users do...

[theodoreb]

We've been shipping Drupal 9 with 3.0.0-rc.0 for more than a year, haven't seen any js-cookie related issue so far on our end. I would welcome a stable release too.

https://www.drupal.org/node/3104677
https://www.drupal.org/project/drupal/issues/3118726

[FagnerMartinsBrack]

@carhartl Shall we just release and deal with the other issues in a minor version? TBH I'm ok with just closing this issue with a release and then dealing with other issues later, even if that means a v4 in a few months/years.

This lib is so stable that just releasing it shouldn't make any harm. I would have a different position if there were 1k issues open to deal with.

[ZhangChengLin]

This lib is so stable that just releasing it shouldn't make any harm. I would have a different position if there were 1k issues open to deal with.

Some people will never use the rc version, and if they don't take a step forward, how do they know what's ahead?

[carhartl]

Ok, the ES module support might warrant a mayor release on its own. For the release I still want to do something about #666 though.

Going to address it later today and do a release.

[emilio-martinez]

@carhartl anything blocking release at this point?

[carhartl]

@emilio-martinez Time?

[carhartl]

I will stop promising stuff.. whenever I find the time to assess #666 and do a release I will do it.

[carhartl]

#666 is merged, but now there‘s a problem with running browserstack tests to be fixed before I can finally release anything.

For one, we needed to migrate from travis.org to travis.com to bring back CI in the first place, but Browserstack tests do not seem to run at all there — I suspect it has to do with the type of credits we have (trial) which may not allow using addons (Browserstack). I doubt our setup will be easy to port to GitHub Actions. I hope it starts working once I‘ve asked for OSS credits.

I can’t run our Browserstack tests locally either. Looks like there‘s a problem with Apple Silicon..

Some more patience please 😀

[carhartl]

https://github.com/js-cookie/js-cookie/releases/tag/v3.0.0