Vendor "graphql-client" and bump "is-my-json-valid" to 2.20.6

[jesec]

This PR contains:

A BUGFIX

Describe the problem you have without this PR

#3495

npm emits a bunch of security warnings.

Notes

I also migrated "graphql-client" to TypeScript. Though, there is still one warning left due to "pouchdb-fetch" (pouchdb/pouchdb#8408).

[pubkey]

Please do not use version ranges.

[jesec]

It is not a good idea for a library to pin dependencies. It prevents dependents from bumping packages, should the need arise, or if there is a security issue. In other cases, it might lead to out of sync dependency trees. Last, if you are busy for a period of time and can't publish new versions, the pinned dependencies will remain a PITA for all dependents.

Anyways, I will leave that decision to you. I pushed the commit you requested.

[pubkey]

Yes all this is true in theory. But in practice, stuff breaks all the time, it did so in the past and it will so in the future.
When a new version is released, the renovate bot will make a PR to this repo with the updated version.

I know that this is not the common opinion, but I had this discussion in the past so often.
When you add a version range and someone runs npm install rxdb, you cannot predict which subdependency version will be installed. And then they come and create issues because nothing works for them. Also a package-lock would not help because the package-lock is not part of the npm package.

[pubkey]

I am not sure if this is a correct use of the license, when we just copy the whole code over to the RxDB repo.
RxDB uses apache2, while graphql-client has set ISC on the package.json, but the repo has no license file.

[jesec]

I am not sure if this is a correct use of the license, when we just copy the whole code over to the RxDB repo. RxDB uses apache2, while graphql-client has set ISC on the package.json, but the repo has no license file.

That project made it clear that it is under ISC with the license field in package.json.

Otherwise, if a repo indicates no license, that means no license. You can't use it in any fashion (not even as a dependency) when that's the case.

---

if you have concern about license compatibility, ISC is permissive, and is compatible with Apache 2.0.

[pubkey]

I am really against copying this code into the RxDB repo.
ISC might be compatible, but it adds more complexity for users when they want to evaluate if the license is ok for them.
Also I would have to maintain this code for a long time which I do not want.
Isn't there another library that we can use?

[jesec]

I am really against copying this code into the RxDB repo.
ISC might be compatible, but it adds more complexity for users when they want to evaluate if the license is ok for them.
Also I would have to maintain this code for a long time which I do not want.
Isn't there another library that we can use?

There might be. But that’s not going to be a drop in replacement.

It is really not that complicated. It is the same thing when you choose to depend on the package. ISC is in no way viral.

[pubkey]

I really do not want to copy over code. I did this in the past. Years on from now, you will long be gone but I will still be sitting there maintaining the code.
Also most non-side-project projects I work with are full of people who are afraid of using any open source tool. I will not make this more complicated by mixing up licenses.

Isn't there some graphql request library that other projects already rely on?

[pubkey]

Closed since no answer.
is-my-json-valid was updated in ded4fdb

[pubkey]

Hi @jesec
I have to admit, you where right, I was wrong.
The graphql-client will be replaced: #4101