non-standard import of EventJS about flagsmith-js-client

[kyle-ssg]

Hi, thanks for raising your concern.

The event library in question is a very small, simple bit of code responsible for triggering an event and the reason for bundling into our application was because the library did not have ES module support but did exactly what we needed. In regards to particular points:

1. this library no longer gets the free updates from the EventJS library so we don't get their performance improvements.
2. this library no longer gets the free updates from the EventJS library so we don't get their security enhancements.

This is quite unlikely the library hasn't been published in 4 years and was only ever published 4 times, probably due to its simplicity.

3. The type information is broken due to that line I linked above.
   No, since the event library does not support TypeScript.

Since this has been brought to my attention, however, I've gone to the effort of bringing this library up to speed as well as improving the community's TypeScript support. #133

[dabeeeenster]

Hey @dgreene1 thanks for this. Happy to take a PR or we can look at this ourselves over the next few days.

[dgreene1]

@dabeeeenster if I was confident that our company was considering this product over the competition I would make a PR. But we’re not there yet. And the findings actually were rather disturbing to see. Like it’s clearly a copy and paste of the minified version of a public library and I can’t understand how that’s acceptable for a paid offering. Since I can’t reverse engineer that minified code to determine which library was used, the Flagsmith staff will have to make this PR.

[dgreene1]

The type information is broken due to that line I linked above.

No, since the event library does not support TypeScript.

That’s a bummer since there are many event libraries that are tiny and have types internally or in DefinitelyTyped. I can’t recall which of these I used in my last library, but the top 4 likely do have types due to their popularity: https://npmtrends.com/event-emitter-vs-event-trigger-vs-eventemitter2-vs-eventemitter3-vs-events-vs-pubsub-js-vs-tiny-emitter

the reason for bundling into our application was because the library did not have ES module support

There shouldn’t be a problem with CommonJS imports if you use this flag: https://www.typescriptlang.org/tsconfig#esModuleInterop

this library no longer gets the free updates from the EventJS library so we don't get their security enhancements.

What I mean by that is that you won’t get Dependabot security alerts for https://www.npmjs.com/package/event-trigger because Github has know way of knowing that you use that library due to it not being in you package-lock.json. So if there is a security exploit in https://github.com/zoli-fischer/event-trigger then you won’t get informed.

That being said, I think #133 is a great contribution and makes me feel more comfortable giving Flagsmith the go-ahead to be one of the libraries that our company considers. Thank you. :)

[kyle-ssg]

That’s a bummer since there are many event libraries that are tiny and have types internally or in DefinitelyTyped. I can’t recall which of these I used in my last library, but the top 4 likely do have types due to their popularity: https://npmtrends.com/event-emitter-vs-event-trigger-vs-eventemitter2-vs-eventemitter3-vs-events-vs-pubsub-js-vs-tiny-emitter

I'll take a look at the event emitters you linked, my main goal for it would be keeping the bundle size low, a few I looked at previously were doing more than we needed.

There shouldn’t be a problem with CommonJS imports if you use this flag:

Thanks for that I'll try it out for my own curiosity, similarly to the comment on Dependabot, I still think the most positive way forward will be to continue with the PR or get an equally small typed replacement.

Thanks for the kind words RE #133, I'll likely be tidying this up / publishing today.

[kyle-ssg]

This is now released as of flagsmith, flagsmith-es and react-native-flagsmith 3.6.0