build: no strict version for kuzzle-sdk

[sebtiz13]

What does this PR do ?

Change kuzzle-sdk version restriction to allow npm to dedup the package when it's required in other package.

Explanation

Currently, Kuzzle require strictly [email protected], if a package like plugin require kuzzle and [email protected]

With strict restriction, NPM produce this install

• [email protected]
• kuzzle
  • [email protected]

With package restriction like kuzzle-sdk@^7.11.3 (so accept greater than 7.11.3 but less than 8), NPM produce this install

• [email protected]
• kuzzle

Here, kuzzle-sdk is not installed in kuzzle directory because [email protected] satisfy the restriction.
Also, normally in future if I want to install [email protected] in my package, npm will throw an error for incompatibility (need to verify, because npm haven't consistent behavior through the versions)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[rolljee]

What does this PR do ?

Change kuzzle-sdk version restriction to allow npm to dedup the package when it's required in other package.

Explanation

Currently, Kuzzle require strictly [email protected], if a package like plugin require kuzzle and [email protected]

With strict restriction, NPM produce this install

• [email protected]

• kuzzle

  • [email protected]

With package restriction like kuzzle-sdk@^7.11.3 (so accept greater than 7.11.3 but less than 8), NPM produce this install

• [email protected]
• kuzzle

Here, kuzzle-sdk is not installed in kuzzle directory because [email protected] satisfy the restriction. Also, normally in future if I want to install [email protected] in my package, npm will throw an error for incompatibility (need to verify, because npm haven't consistent behavior through the versions)

Wouldn't it be a best practice to update the sdk to his latest version but still left fixed to avoid issue ?

Like we could launch an action that launch ncu and update if all tests aren't failing ?

[sebtiz13]

What does this PR do ?

Change kuzzle-sdk version restriction to allow npm to dedup the package when it's required in other package.

Explanation

Currently, Kuzzle require strictly [email protected], if a package like plugin require kuzzle and [email protected]
With strict restriction, NPM produce this install

• [email protected]

• kuzzle

  • [email protected]

With package restriction like kuzzle-sdk@^7.11.3 (so accept greater than 7.11.3 but less than 8), NPM produce this install

• [email protected]
• kuzzle

Here, kuzzle-sdk is not installed in kuzzle directory because [email protected] satisfy the restriction. Also, normally in future if I want to install [email protected] in my package, npm will throw an error for incompatibility (need to verify, because npm haven't consistent behavior through the versions)

Wouldn't it be a best practice to update the sdk to his latest version but still left fixed to avoid issue ?

Like we could launch an action that launch ncu and update if all tests aren't failing ?

The problem it's if we use the version 7.11.1 in the core and then we have a 7.11.3 update. We need to release the core only to update the package version. Instead, with not strict restriction, It's not mandatory to release the core only for that.
It's for this reason we restrict the version range of package with caret ^ to accept only from 7.11.1 to 8 (not include) to ensure the compatibility (in theory no breaking change), but we can be stricter and use tilde to restrict the range only on patch so from 7.11.1 to 7.12 (not include) to be safer.

[rolljee]

What does this PR do ?

Change kuzzle-sdk version restriction to allow npm to dedup the package when it's required in other package.

Explanation

Currently, Kuzzle require strictly [email protected], if a package like plugin require kuzzle and [email protected]
With strict restriction, NPM produce this install

• [email protected]

• kuzzle

  • [email protected]

With package restriction like kuzzle-sdk@^7.11.3 (so accept greater than 7.11.3 but less than 8), NPM produce this install

• [email protected]
• kuzzle

Here, kuzzle-sdk is not installed in kuzzle directory because [email protected] satisfy the restriction. Also, normally in future if I want to install [email protected] in my package, npm will throw an error for incompatibility (need to verify, because npm haven't consistent behavior through the versions)

Wouldn't it be a best practice to update the sdk to his latest version but still left fixed to avoid issue ?
Like we could launch an action that launch ncu and update if all tests aren't failing ?

The problem it's if we use the version 7.11.1 in the core and then we have a 7.11.3 update. We need to release the core only to update the package version. Instead, with not strict restriction, It's not mandatory to release the core only for that. It's for this reason we restrict the version range of package with caret ^ to accept only from 7.11.1 to 8 (not include) to ensure the compatibility (in theory no breaking change), but we can be stricter and use tilde to restrict the range only on patch so from 7.11.1 to 7.12 (not include) to be safer.

If I understand in this case,

Does it mean in the case we have kuzzle requesting the 7.11.1 and another repo is requesting 7.11.3
It will install the 7.11.3 right ?

So it also mean that kuzzle will too run in 7.11.3 even tho it as only be tested with the 7.11.1 ?

I think I am okay with it, but I just want to be fully aware of all that :)

[kuzzle]

🎉 This PR is included in version 2.31.0-beta.1 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[kuzzle]

🎉 This PR is included in version 2.31.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀