Fixed an issue where cookies destinations were not set to the correct path.

Description

Let's say you start with a js-cookie instance:

import export default {
  get: cookie.get,
  set: cookie.set,
  remove: cookie.remove,
  withConverter: cookie.withConverter
}; from 'js-cookie'

You will get back an object that has the regular methods (get, set, remove). The object contains also an attributes property that by default has the value {path: '/'}. If you then call

Cookies.set('name', 'value');

the cookie's path will be /.

If then we would do:

Cookies = Cookies.withConverter({ write: function () { .... } });
Cookies.set('name', 'value');

The cookie's path will still be / in this case. js-cookie is supporting this scenario here. Pay attention that the code uses this.attributes.

We are using js-cookies in a different way here:

export default {
  get: cookie.get,
  set: cookie.set,
  remove: cookie.remove,
  withConverter: cookie.withConverter
};

We then call in the Audience module cookieJar.withConverter. At this point, we will get back as instance without the default path being /. That happens because the this.attributes in js-cookie code will refer to the object that we export in the cookieJar.js file. And that object doesn't contain any attributes property.

Initially I was thinking to just export the js-cookie module inside cookieJar.js. The cookieJar code would have become something like this:

import cookie from "js-cookie";
export default cookie;

There is a problem though. The Cookies variable that is imported is an object that contains 2 properties: attributes and converter.

The methods get, set and remove are set on the prototype chain of that object.

And when we do here

 return {
    ...cookieJar,
    set(key, value, options) {
        ...
    },
  };

the spread operation is working only on the properties. Not on the whole prototype chain. The result was that you would have got back an object that didn't contain get or remove properties anymore. This is why I got to the solution that Jon suggested to bind the js-cookie initial context.

Motivation and Context

Screenshots (if appropriate):

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Improvement (non-breaking change which does not add functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have signed the Adobe Open Source CLA or I'm an Adobe employee.
[x] I have made any necessary test changes and all tests pass.
[x] I have run the Sandbox successfully.

adobe / alloy