feat: exclude deprecated and prerelease versions from completion + add config

[nitodeco]

Resolves #25

Config option:

Default disabled:

Excludes deprecated versions completely. @9romise Do you think we need an option to show those as well?

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a new boolean configuration npmx.completion.excludePrerelease (default true) to exclude prerelease versions from completion suggestions and updates README table layout to include the option. Introduces an exported PRERELEASE_PATTERN RegExp (/-.+/) in src/constants.ts. The version completion provider now skips entries where meta.deprecated is set and, when npmx.completion.excludePrerelease is true, skips versions matching PRERELEASE_PATTERN. No public APIs were removed or altered.

Possibly related PRs

• feat(completion): support 'npm:'-prefixed versions #29: Modifies src/providers/completion-item/version.ts by rewriting version parsing/formatting and semver handling, affecting selection of version candidates.
• refactor: enhance version parsing with protocol support and validation #30: Changes src/providers/completion-item/version.ts to adjust which version entries are emitted by completion, including protocol/validation logic.
• refactor: migrate to fast-npm-meta #18: Restructures iteration and adds provenance/tag-based filtering in src/providers/completion-item/version.ts, altering version completion-item generation.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The pull request description is related to the changeset and references the linked issue #25, demonstrating clear connection between the description and code changes.
Linked Issues check	✅ Passed	The pull request successfully addresses issue #25 by excluding deprecated and prerelease versions from completion suggestions, implementing both filtering logic and user-configurable settings.
Out of Scope Changes check	✅ Passed	All code changes directly support the objectives of filtering versions in completion lists; README, package.json, constants, and version provider modifications are all in-scope and necessary for the feature.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[9romise]

Wow! Excellent idea.

Excludes deprecated versions completely. @9romise Do you think we need an option to show those as well?

I think filtering out deprecated versions directly is perfectly fine. If someone requests to see them, we can always provide an option for that time — but I doubt anyone would intentionally select a deprecated version when updating, right? 🤔

[9romise]

Could we place this option under the version level? For example: npmx.completion.version.prelease.

[RYGRIT]

I appreciate the forward-thinking!

However, I feel that exposing 3 separate boolean flags just for version completion might be a bit too verbose/complex for the user.

I’d prefer a simpler Enum + Boolean pattern:

npmx.completion.version: Enum (Controls the source/strategy, e.g., "all" vs "provenance")

npmx.completion.excludePrerelease: Boolean (Independent filter)

This keeps the config clean while still covering the necessary logic. Since we're in preview, keeping the API surface small seems like a safer bet. WDYT?

[nitodeco]

npmx.completion.version: Enum (Controls the source/strategy, e.g., "all" vs "provenance")
npmx.completion.excludePrerelease: Boolean (Independent filter)

I like this, not too verbose and easy to expand

[9romise]

Ok! Then lets do this!

[nitodeco]

[coderabbitai]

Actionable comments posted: 1

[RYGRIT]

The PRERELEASE_PATTERN seems a bit too restrictive.

Using a whitelist (alpha|beta|rc|canary) will miss many common prerelease tags, such as next (e.g., vue@next), dev, or nightly.

Suggestion: Since SemVer defines a prerelease as anything following a hyphen, a generic regex would be safer:

// Matches any version containing a hyphen
export const PRERELEASE_PATTERN = /-.+/;

(Or use semver.prerelease() if the package is available.)