New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can I help modernize the package? #528
Comments
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? |
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.
I believe adding support for bundlers like Rollup and Webpack is just declaring the ESM version of the package in the package.json This is to prepare for using ES modules in node. Here is an awesome writeup for what's to come. |
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
Yes, at least. Elsewhere it was suggested to also drop support for IE 10 even if I remember correctly. |
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 |
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
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? 😆 |
I thought of a use case where one only needs to write cookies, and then would be able to import just the respective module.
Not so fast :) |
I'm going to spike something, and probably start the work on v3.. |
I‘m going to close this, there are going to be separate issues, as part of the v3 milestone. |
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. |
Absolutely! Let me know if there is anything I can do to help. Glad this is moving along. |
Regarding TypeScript, I started working on ts-cookie, based on js-cookie v3: https://github.com/carhartl/ts-cookie |
First, let me say that I really love this package! But there are a few shortcomings:
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?
The text was updated successfully, but these errors were encountered: