Can I help modernize the package?

[markcellus]

First, let me say that I really love this package! But there are a few shortcomings:

1. it isn't interoperable with third-party bundlers like webpack
2. doesn't have built-in typescript support
3. doesn't support ES6 syntax

Instead of creating yet another cookie lib, I'd really like to add this feature set to this package which could help a lot of the developers who are expecting these features. Is this something you all are open to?

[carhartl]

Hi Mark, these are welcomed suggestions. Some of these things I had in mind for a fully modernized v3 release of the plugin, where we’d be dropping support for old browsers. Though before I am willing to begin any of that we need to fix automated testing in at least those browsers we would want to support there, see #524.

I’m still not convinced about TypeScript support though, we have had requests and discussions about in the past. We could start without though.

What would be required to support webpack?

[markcellus]

Sure, using all features of TypeScript is optional. But it should at least have a type declaration file which would make the package interoperable on projects that use TypeScript.

What browsers did you plan to drop in v3? Oh, actually I see #370 lists that support is being dropped for IE 7, 8, and 9?

What would be required to support webpack?

I believe adding support for bundlers like Rollup and Webpack is just declaring the ESM version of the package in the package.json module field. Webpack talks about it here and Rollup talks about it here.

This is to prepare for using ES modules in node. Here is an awesome writeup for what's to come.

[carhartl]

Ah, I've been reading the following the other day: https://philipwalton.com/articles/using-native-javascript-modules-in-production-today/

I find it appealing to migrate our codebase to one or more than one ES module while modernizing. On the other hand I always found it to be an advantage to not require any additional build step for packaging up the code one way or the other for compatibility; maybe these days that's no longer that relevant, because either browsers support modules natively or webpack etc. is a commodity in almost all projects.

The idea I had is that we could be providing separates modules for reading + writing cookies, and another "meta" module combining the two and giving us the well-known Cookies based api. Not sure, if it's that's really needed/useful, could be suffering from "wanting too much".

What browsers did you plan to drop in v3? Oh, actually I see #370 lists that support is being dropped for IE 7, 8, and 9?

Yes, at least. Elsewhere it was suggested to also drop support for IE 10 even if I remember correctly.

[carhartl]

Writing down some more notes..

Currently we’re producing a minified version for a release. If we were to migrate this library to an ES module, we could provide a minified mjs file and additionally a minified “nomodule” version. This would solve #501. We would have to have a slightly more complex build environment for this, using Rollup or webpack. I hope this makes sense.

[markcellus]

Absolutely! That sounds like an awesome plan. I have a similar setup here on one of my packages. I produce an ES module version, a commonjs version (bundled and minified) and a declaration file for consumers who use TypeScript.

we could be providing separates modules for reading + writing cookies, and another "meta" module combining the two and giving us the well-known Cookies based api.

This could make sense as long as all of it gets compiled into one module file for consumers, but I can see you breaking things up if it helps to better maintain the codebase.

Dropping IE 10 seems reasonable. Especially given the fact that most major applications have also dropped support for it. There's still a case to be had about IE11 though. I work for a pretty large health care company and although we want to drop support for our IE11 users, there is still a big market for it, unfortunately.

This all sounds great! I guess you don't really need me then, huh? 😆

[carhartl]

This could make sense as long as all of it gets compiled into one module file for consumers, but I can see you breaking things up if it helps to better maintain the codebase.

I thought of a use case where one only needs to write cookies, and then would be able to import just the respective module.

I guess you don't really need me then, huh?

Not so fast :)

[carhartl]

I'm going to spike something, and probably start the work on v3..

[carhartl]

I‘m going to close this, there are going to be separate issues, as part of the v3 milestone.

[carhartl]

My impression is that once we have a complete rollup setup we will be able to remove Grunt as well. Nothing that we can‘t implement using npm scripts.

[markcellus]

Absolutely! Let me know if there is anything I can do to help. Glad this is moving along.

[carhartl]

Regarding TypeScript, I started working on ts-cookie, based on js-cookie v3: https://github.com/carhartl/ts-cookie