1.0.8 — Release/publish precheck hardening and lockfile tracking

Main story

This release is primarily about stabilizing the publish/release process rather than changing runtime behavior. It hardens prerelease publishing prechecks by making installs reproducible and by aligning project metadata with the prerelease publishing workflow.

Changes in 1.0.8

Publish & release workflow hardening

• Lockfile is now tracked (package-lock.json added to the repo) to make dependency resolution deterministic and to satisfy publish prechecks/validation consistently.
• publishConfig.tag is set to dev in package.json, aligning default publishes with the prerelease/dev distribution channel used by the workflow.

Why it matters

• CI and local installs are less likely to drift due to semver-resolved devDependency changes.
• Automated prerelease checks should behave consistently across environments.

Repo hygiene

• .gitignore was adjusted (one line removed) as part of ensuring the lockfile policy works as intended (i.e., the lockfile is no longer treated as an ignored artifact).

Version bump

• Package version is now 1.0.8 in package.json.

Impact for users and developers

For consumers

• No functional/runtime code changes were included in this release (no src/** changes in this range).
• Important publishing note: because publishConfig.tag defaults to dev, installs that rely on the default latest dist-tag may not pick up 1.0.8 unless your release automation overrides the tag when publishing production releases.

For maintainers/contributors

• Expect more reproducible installs due to the checked-in lockfile.
• Publish/pipeline validations should be more predictable.

Breaking changes

• No API or runtime breaking changes were detected in this release.
• Potential distribution behavior change (process-level): the default npm publish dist-tag is configured as dev. If you previously expected npm publish (without flags/overrides) to publish to latest, you will now need to explicitly manage dist-tags in your release process.