A simple, lightweight JavaScript API for handling browser cookies
defaults
in favor of a builder: now to supply an api instance with particular predefined (cookie) attributes there's Cookies.withAttributes()
, e.g.:const api = Cookies.withAttributes({
path: '/',
secure: true
})
api.set('key', 'value') // writes cookie with path: '/' and secure: true...
attributes
property; it's an immutable object and unlike defaults
cannot be changed to configure the api.Cookies.converter
, which allows for implementing self-contained custom converters providing the same behavior:const customReadConverter = (value, name) => {
if (name === 'special') {
return unescape(value)
}
return Cookies.converter.read(value)
}
withConverter()
no longer accepts a function as argument to be turned into a read converter. It is now required to always pass an object with the explicit type(s) of converter(s):const api = Cookies.withConverter({
read: (value, name) => unescape(value)
})
converter
property; it's an immutable object and cannot be changed to configure the api.module
field in package.json
points to an ES module variant of the library.browser
field instead of main
in package.json
(for the UMD variant of the library).getJSON()
and automatic stringifying in set()
: use Cookies.set('foo', JSON.stringify({ ... }))
and JSON.parse(Cookies.get('foo'))
instead.Reverted changes introduced in rc2, which caused a mayor breaking change in the case of requesting the library via jsdelivr CDN with a particular file name. This breaking change was not intentional.
The problem was that we've been advertising the following link in the readme on the master branch:
https://cdn.jsdelivr.net/npm/js-cookie@rc/dist/js.cookie.min.js
while the respective change had changed that file name in the distribution to js.cookie.umd.min.js
.
Nonetheless, we advise to always use the latest stable version in production environments.
exports
field in package.json - #695browser
field instead of main
in package.json (for the UMD variant of the library): bundlers by default prefer it over module
and will end up with a UMD module where ES may be preferred - #666