currently the versioning of this library is 0.0.x.
This library is distributed via https://npmjs.org - therefore semantic versioning is enforced by all consuming dependency management systems.

The problem i see: according to semantic versioning each version of 0.0.x is identified as a breaking change.
This means: projects that require this very library usually do this via ^0.0.x - so if they depend on ^0.0.1 they are incompatible to any later version - dependency management tools will not install it because ^0.0.1 conflicts with 0.0.6 and this conflicts with 0.0.7
This means: projects that use multiple downstream libraries that require different versions of this library wlll force pnpm, yarn, npm and others package managers to fail (or install multiple different versions to be installed). This leads to a dependency mess.

See some example downstream usage:

• https://github.com/sonatype-nexus-community/js-sona-types/blob/main/package.json#L76 -- ^0.0.5
• https://github.com/EngCpp/dependency-track-node-module/blob/master/package.json#L47 -- ^0.0.1
• https://github.com/CycloneDX/cyclonedx-node-module/blob/master/package.json#L62 -- ^0.0.6
• https://github.com/CycloneDX/cyclonedx-node-npm/blob/1.0-dev/package.json#L46 -- ^0.0.7
• https://github.com/CycloneDX/cyclonedx-javascript-library/blob/main/package.json#L42 -- >=0.0.6 <0.0.8

solution: Just release a 1.x.x version.
This library will never be feature complete, because PackageURL is a living standard that is never complete. SO keeping a 0.x.x or even 0.0.x version strategy is an unnecessary obstruction.
Releasing a major version would enable you to finally use proper semantic versioning with major(breaking) , minor(feature) and patch(bugfix) sub versioning.

see also NPM's version tester, to experience the impact : https://semver.npmjs.com/