Is adding the version number mandatory? I’d like to always get the latest version, therefore not specifying the version number (assuming newer versions are always upwards compatible). Or is that considered unwise and bad practice?
So, my guess is that something is missing somewhere to make just "fraction.js" refer to the most recent revision?!
Is that something Fraction.js can/should fix on the JS module side? (I’m a lay person in that area).
Some more confusion: on https://semver.npmjs.com I see that current revision is 4.3.6?! But when I require('fraction.js@4.3.6'), I get a load error.
Without commenting on the rest of your post, and I haven’t looked at this library in particular, I’ll comment on this part in particular:
I think this is bad practice. Many libraries break compatibility with upgrades, even between major versions. If you want any software you write (including Observable notebooks) to work going forward, it is worth while to pick specific versions of your dependencies and stick with them. Otherwise you’ll constantly be chasing compatibility issues like this.
Do you know if there are conventions about major and minor and subminor versions? For example, when a major revision number changes, it may imply incompatible changes (e.g. API, behaviour, side-effects). And when subminor versions change, it always is compatible change?
There is a commonly cited convention called Semver (which you seem to be at least partially aware of). Semver has a lot of details, but the basics boil down to this: If you have a version number like X.Y.Z, then X is called the major version number, Y is called the minor version number, and Z is called the patch version number.
If a change to the software is both backwards and forwards compatible, then a new version that includes that change must increment the patch number. This is often bug fixes or documentation changes.
If a change to the software introduces changes that are backwards compatible, but not forward compatible, then the minor patch number must be incremented. That means that software written for 2.5.1 would be expected to work in 2.6.0, but that software written for 2.6.0 can’t be guaranteed to work with 2.5.1. These kind of changes are usually new features.
Finally, if a change introduces a change that is not backwards compatible, it must increment the major number. Software written for 2.5.1 can not be guaranteed to work with 3.0.0. This is often major new features, or changes in the support of underlying languages (like dropping support for old versions of Node, for example).
(There is more to Semver than that. If you want to know more you can read about it here: https://semver.org/)
So, with all that in mind in theory an upgrade from 4.0 to 4.3.6 should not break compatibility. However, as you’ve seen first hand this is not always true. What one person considers a breaking change another person might see as fixing a bug. And some projects use Semver-like versions without actually conforming to Semver.