Prepare the `next` branch for release

[apucacao]

#53 now lives on the branch next. Once the few items below are fixed, we'll publish to npm with the next tag. (So npm install ldclient-node@next works.)

Tasks:

• fix linting errors
• make sure tests can run successfully locally
• minor: increase prettier max line length to 120 — 80 causes tests names to wrap in strange ways

[apucacao]

@tdeekens I'm collecting things that need to happen before we can merge next into master here. I've also published the @next version to npm.

[tdeekens]

Thanks! I am trying to follow: we should address the things stated above before we publish to @next or did you already?

[apucacao]

I just published @next to npm. I think we should fix those issues before we can merge next into master.

[tdeekens]

Ah, yeah sure. Makes total sense. I am only "worried" about getting the tests to run properly.

[tdeekens]

Little update

Released the launchdarkly-adapter at flopflip to @next with a js-client from @next

Building the js-client from ESM to CJS works fine. Bundle sizes have not changed at all interestingly. Just wanted to make sure we don't leak anything more to clients.

From @latest:
Destination: dist/@flopflip-launchdarkly-adapter.cjs.js
Bundle size: 6.07 KB, Gzipped size: 1.92 KB

to @next
Destination: dist/@flopflip-launchdarkly-adapter.cjs.js
Bundle size: 6.07 KB, Gzipped size: 1.92 KB

Tested the js-client from the @next release

This currently causes problems due to the exports changing from the CJS to ESM style in the diff

- module.exports = {
-   initialize: initialize	
- };

+ export default {
+   initialize,
+ };

as this breaks and does not work any more

import { initialize } from 'ldclient-js';

return initialize(clientSideId, user);

and would have to be rewritten to

import ldClient from 'ldclient-js';

return ldClient.initialize(clientSideId, user);

I guess we could also change it to a named export to potentially avoid breaking changes towards users of the library.

[apucacao]

I think ensuring the library is backward-compatible would be ideal. Using a named export like you suggest would ensure that, right?

[tdeekens]

Yes, I think it should. I can test it on my integration branch at flopflip to make sure. Some set of linters might not get too excited about it as they would suggest to prefer a default export in that case.

Update, #63 addresses that.

[tdeekens]

That leaves us "only" with the tests locally no running. My karma knowledge gotten a bit rusty over the last year. Do you have any idea what might cause this?

26 12 2017 17:41:28.833:DEBUG [web-server]: Instantiating middleware
26 12 2017 17:41:28.834:DEBUG [reporter]: Trying to load reporter: mocha
26 12 2017 17:41:28.836:DEBUG [reporter]: Trying to load color-version of reporter: mocha (mocha_color)
26 12 2017 17:41:28.836:DEBUG [reporter]: Couldn't load color-version

I don't have much of a clue where to start digging. Personally I'd like the project to be moved over to Jest and Circle@2 in the future. What are your plans there?

[apucacao]

Hmm, not sure what's going on…

We switched to Jest for our other projects, and it would be great if we could do this here as well. Does switching to Jest require that we also switch to circle 2?

[tdeekens]

Nope it doesn‘t. Switching to Jest would mean something like:

• Running some codemods to move from mocha and chai
  • Then fixing up one or two things maybe
• Removing sinon as we can use jest.fn
  • Only concern is the usage of sinons http server stubbing ive seen used
• CircleCI v2 would be optional and could be another PR

[apucacao]

I'll take a look to see if there any utils that could help with mocking an HTTP server for Jest.

---

Update: On second thought: could we keep using sinon's fake http server for now? We can still use jest.fn for simple mocks, but that way we can defer the sinon question?

[apucacao]

/cc @brooswit

[tdeekens]

That would work. Maybe it's worth not having sinon as a global but just import it. That's another thing however.

[apucacao]

That was successful: we're not using jest with sinon in a few places. All tests pass, all linting errors are gone.

I'm going to publish the latest @next to npm so that we can do some real-life testing.

Update npm install ldclient-js@next will now install the latest version of this branch.