Tighten Ocsigen Start & Toolkit version constraints

[vasilisp]

Also drop problematic npm external dependency.

See discussion in #11380. CC @jpdeplaix.

[camelus]

✅ All lint checks passed 71d10fa

• These packages passed lint tests: ocsigen-start.1.0.0, ocsigen-toolkit.0.99, ocsigen-toolkit.1.0.0

---

✅ Installability check (8293 → 8293)

[kit-ty-kate]

Mmh could you explain where npm was used exactly ? Is it a runtime dependency ?
If you want to remove it because it was just a convenient tool to have installed, could you also remove the depext for ubuntu ?
If it's a runtime dependency maybe it's ok to let it here and thing on our side to upgrade to debian unstable as a first target or something like that.

[vasilisp]

Ocsigen Start consists of a library and an application skeleton. The build system of the latter (in its default configuration) uses npm to install needed dependencies. The dependency arises when you build the template, but not when you opam install ocsigen-start.

These depexts are meant to produce a configuration that permits getting started with ocsigen-start very quickly. To this end, auto-installing npm on distributions that provide it (like Ubuntu) is a good idea. Theoretically you can install everything by hand (without npm), but that would be way too much effort.

Debian has practically abandoned the npm package and upgrading to unstable for its ancient npm is no solution. Debian users would need to install npm by non-Debian means.

I understand that all this is not very coherent with how OPAM packages normally behave. I am not at all happy with the Ocsigen Start design choices myself. But if we want to make Ocsigen Start usable via OPAM, we need such depexts :).

[samoht]

looks good to me, thanks for the explanation about npm.