Breaking change introduced in a minor version (1.6.0) without major version bump

Hi anvaka,

First off, thank you for maintaining this library. I’ve found it very useful.

I’m writing to report a potential violation of [Semantic Versioning](https://semver.org/) that has caused a breaking change in my project.

In version 1.6.0, released two years ago, the module was refactored from CommonJS to ES Modules. While this is a great modernization, it is a breaking change for any downstream project that uses require() to import the library.

According to SemVer rules, any change that breaks backward compatibility must be accompanied by a major version bump (e.g., from 1.5.0 to 2.0.0), not a minor version bump.

The Problem:

My project, which was working perfectly with v1.5.x, broke after the dependency was automatically updated to v1.6.0 because my code uses require():

```
// My code that worked with v1.5.x
const ngraph_path = require("ngraph.path");
```

After the update to v1.6.0, I now get the following error:
```
Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: ...
require() of ES modules is not supported.
```
Suggested Solution:

To prevent this from affecting other users, could you please consider one of the following options?

(Recommended) Yank the problematic versions (1.6.0 and any subsequent minor versions with this breaking change) and release a new major version 2.0.0 that correctly signals the breaking change. This is the most SemVer-compliant approach.
As an alternative, you could publish a new 1.x patch (e.g., 1.6.1) that reverts to CommonJS and clearly documents that the move to ESM will happen in the next major release.
This issue is not just about my project; it affects anyone who relies on automated dependency updates and expects SemVer to protect them from breaking changes.

Thank you for your time and consideration.

Compare the 1.5.x and 1.6.0 module entry points and package configuration to confirm when CommonJS support was removed. Review the reported require() failure and the SemVer implications, then determine which release behavior and compatibility guarantees should be documented as done.

Written by the indexing model from the issue text.