Update to latest

[9romise]

Update the version with one click.

We could take inspiration from Version Lens or similar tools.

[RYGRIT]

Hi @9romise! I've implemented two different approaches for the 'Update to latest' feature:

1. Quick Fix approach
   This uses a diagnostic squiggle to indicate outdated versions.

• Pros: Cleaner UI, doesn't shift code lines.
• Cons: A bit more clicking required.

freecompress-2026-02-07.16-46-26.mp4

2. CodeLens approach (similar to Version Lens)
   This adds an inline clickable action and supports an 'Update All' command.

• Pros: One-click updates, very efficient.
• Cons: Adds visual noise and extra vertical space.

freecompress-2026-02-07.16-40-51.mp4

My Question:
Which experience do you think fits vscode-npmx better? Or should we perhaps support both and let users toggle them via settings? I'd appreciate your advice!

If you have a completely different vision or feel neither of these fits, please let me know—I'm open to trying whatever works best for the project!

[nitodeco]

@RYGRIT Personally I'd go with a hybrid. I prefer the UX of the quick fix, because it doesn't shift around the layout of the package.json. The fix-all command is very neat tho and something I can see myself using a lot.

Another idea: What about next to an Update to latest-function, there's also a Update to latest patch or Update to latest minor? In a lot of cases I don't wanna upgrade to the latest major version in a project, but ideally to the latest minor version before the next major version, or to the latest patch version before the next minor version.

@9romise @RYGRIT wdyt?

[9romise]

Sorry for the late reply! Thank you very much for your contribution!

I think we could offer both options and let users choose.

I’ve actually implemented both approaches locally but kept them as personal drafts.
The quick‑fix version isn’t fully polished yet, though I believe the diagnostic severity could be set to DiagnosticSeverity.Hint to reduce its impact on users.

For the version‑lens‑like approach, I built a prototype that I’ll review and submit as a PR soon. And I think we can give more choices to users, like patch, satisfied, latest, and so on. We could even provide suggestions based on the version prefix (^, ~) the user has set.

I’m also looking forward to your PR—please don’t hesitate to submit it just because we’ve been working on similar ideas. I believe we can each learn something from the other’s implementation, and we can then pick and refine one of them to merge.

[RYGRIT]

Yes, I also prefer a combination of the two approaches, but I haven't figured out how to configure it, which method to choose by default, etc.

What about next to an Update to latest-function, there's also a Update to latest patch or Update to latest minor?

I think we can give more choices to users, like patch, satisfied, latest, and so on.

As @nitodeco mentioned, @9romise also suggested that Update to latest patch or Update to latest minor should indeed be added. However, since I only have the most basic ideas at the moment, I haven't considered these situations yet.

We could even provide suggestions based on the version prefix (^, ~) the user has set.

I think this is a fantastic idea. 👍

Sorry @9romise , as mentioned earlier, this is still a very preliminary idea. I think the current plan is not mature enough (or rather, it's still quite rough). I will refine it further and submit a PR as soon as possible.

[9romise]

I think the two features you mentioned do not appear to be mutually exclusive, so both could be enabled by default—particularly the diagnostic ones, since their prompts are subtle enough.

As for the version‑lens and #33, I’m still not entirely sure yet. Perhaps we could offer both and turn them on by default to ensure discoverability, but we should also give users the option to turn them off.

[RYGRIT]

As for the version‑lens and #33, I’m still not entirely sure yet. Perhaps we could offer both and turn them on by default to ensure discoverability, but we should also give users the option to turn them off.

I agree providing options to configure the display style is definitely the correct approach.

However, my main concern with enabling both by default is the significant increase in vertical height (visual noise). If every dependency has multiple annotations, the package.json file might become too long and harder to scan.

[9romise]

However, my main concern with enabling both by default is the significant increase in vertical height (visual noise). If every dependency has multiple annotations, the package.json file might become too long and harder to scan.

Currently, the feature that might cause increased visual density is primarily the version‑lens, while #33 is just an inline indicator. I’m also worried that excessive hints will clutter the interface and ultimately get in the way of the user experience.