refactor(universal-cookies): replace “cookie” with “cookie-es”

[robinscholz]

With cookie-es there is now a modern, typed drop-in replacement for the cookie package. This pull request simply replaces the dependency and removes the now obsolete @types/cookie dependency.

This solves an issue within VueUse’s useCookies when used within Nuxt.

As far as I am aware, this should be fully backwards compatible and should not introduce any breaking changes. The cookie-es package provides an export for require.

It’d be great if this change could be considered! Let me know of any thoughts and concerns.

[eXon]

Hi @robinscholz,

Thank you for proposing this change. After careful consideration, I don't think this library has the level of support and maintenance that is needed for being considered as a dependency on this project. I am open to other proposition, but this one does not meet the requirements.

[robinscholz]

@eXon

Thanks for considering and thanks for all the work that already went into this package.

Could you elaborate? What would need to change in terms of support and maintenance? The suggested package is already used by 107k other projects/packages according to Github. The UnJS team has been around for a while as well.

It seems that the original dependency cookie is slow/hesitant to add ESM support, whereas the whole JS ecosystem is slowly, but surely moving in that direction. I believe this will inevitably lead to more problems in the future for projects using universal-cookie.

Curious to hear your thoughts on the matter.

[eXon]

Hi @robinscholz

While 103k weekly downloads might seems a lot, it's not that much. Just to give perspective cookie has 45M weekly downloads. It also hasn't been updated for more than 9 months and doesn't support partionned cookies. I would rather wait for jshttp/cookie#154 getting merged and upgrade the dependency. I agree they seem to be moving slowly, we all have our day job and family but I would argue cookie-es isn't significantly better.

I'm curious on the pain this is creating with Nuxt. Is this library completely unusable and crashing or is this crashing only for some specific use case?

[eXon]

@robinscholz As an alternative, I'm looking into transforming the cookie library into ESM within the build process using https://www.npmjs.com/package/@rollup/plugin-commonjs. I'm testing it a little bit but it looks promising.

[robinscholz]

@eXon That might be a solid solution as well 🙂 At least until the aforementioned pull request for cookie gets merged.

VueUse provides a wrapper for this package called useCookies. Nuxt on the other hand provides their own composable called useCookie, which is built on top of cookie-es

We are in the early stages of building a library of Vue specific plugins and composables called Vue Equipment , which includes a plugin for a Cookie banner build around VueUse’s useCookies. universal-cookie is thus a peer dependency of Vue Equipment.

We are now running into problems with HMR in nuxt, even if we import seemingly unrelated parts of other Vue Equipment plugins:

import { ScrollProgressKey } from '@maas/vue-equipment/plugins'

The /plugins export is a barrel file:

export * from "./MagicCookie/index.mjs";
export * from "./MagicDrawer/index.mjs";
export * from "./MagicMarquee/index.mjs";
export * from "./MagicModal/index.mjs";
export * from "./MagicNoise/index.mjs";
export * from "./MagicPlayer/index.mjs";
export * from "./MagicScroll/index.mjs";
export * from "./MagicToast/index.mjs";

For some reason nuxt evaluates all exports here and throws a Cookie is not a constructor error. We tried transpiling cookie with the nuxt vite settings, but with no success. The only workaround for us currently is to be explicit about imports:

import { ScrollProgressKey } from '@maas/vue-equipment/plugins/MagicScroll'

This is something we’d like to avoid if possible.

I haven’t tested if we can actually use our MagicCookie plugin within nuxt without problems, but I Imagine it might also cause problems.

Overall its a rather specific problem, but I thought it'd be good to try and get to the root of it, which in my opinion is the lack of an ESM export in cookie.

I understand your reasoning as well, your proposed solution seems like a good workaround/temporary fix. Let me know if I can be of any help!

[eXon]

@robinscholz It has been changed in 7.1.0 that just got released. Feel free to try it.

[robinscholz]

@eXon Never got arround to replying … sorry.

Thanks for working on a fix, the issues we had are solved 🙂