FFL-1633 chore: upgrade dependencies to resolve audit warnings

[dd-oleksii]

Eppo Internal:

🎟️ Fixes FFL-1633

Motivation and Context

Upgrade dependencies to fix all audit warnings.

Description

How has this been documented?

How has this been tested?

[greghuels]

It looks like you ran yarn upgrade, which should work so long as authors of the libraries of our dependencies respect backwards compatibility. If you want a more surgical approach, I would run yarn upgrade express, which will only upgrade express and will still upgrade the qs transitive dependency to 6.14.1.

[aarsilv]

I would vote for the surgical approach, also we should get the CI/CD passing. It's unclear to me why it is not 🤔

[dd-oleksii]

Is there any reason you prefer "surgical" approach?

1. It leaves quite a few of smaller vulnerabilities
2. Our lockfile does not affect our users (only package.json does) so it ultimately does not matter except for CI
3. Having older dependencies pinned means we're not testing against the latest versions of dependencies, so might hide incompatibilities (that are going to be discovered by our users). The usual suggestion for libraries is to not commit lock files at all

[dd-oleksii]

It looks like CI is failing because it's trying to pull from the wrong repository (this one instead of my fork):

react-native-sdk/.github/workflows/ci.yml

Lines 32 to 36 in ad436d1

	- name: Checkout
	uses: actions/checkout@v3
	with:
	repository: Eppo-exp/react-native-sdk
	ref: ${{ env.SDK_BRANCH_NAME}}

Can someone add me to the repo (or the org), so I can reopen?

[aarsilv]

My impression is that we should update package.json to get this SDK to minimum versions that don't have the vulnerabilities, and since we're modifying that was thinking we be more targeted rather than upgrading everything. However I am fine with doing all the upgrades necessary to address known vulnerabilities, and if that is nearly everything we can just upgrade it all.

I've added you to the repository (didn't realize the datadog-specific user name) so hopefully we'll be good to go on that front.

Note that this is has an example app, please test with that using a QA base url and key and ensure it makes a non-default assignment successfully. If you need help with that, happy to pair!

[dd-oleksii]

oh.... pushing the same commit to base repo has fixed the CI 🤪 so I guess we can continue here

My impression is that we should update package.json to get this SDK to minimum versions that don't have the vulnerabilities

Given that the vulnerable dependency is transitive (not in our direct dependencies), I don't think we should do that. We just need to make sure that our dependency constraints in package.json don't prevent our users from upgrading.

Note that this is has an example app, please test with that using a QA base url and key and ensure it makes a non-default assignment successfully. If you need help with that, happy to pair!

oh, this change does not affect the example app 🙂. The example has its own lock file which is still vulnerable (in another way). I've updated it too and tested that example app still works 🫡

[aarsilv]

We just need to make sure that our dependency constraints in package.json don't prevent our users from upgrading.

Ah I see what you are saying now! Ok this makes sense... carry on!