Nimblesite / Nimblesite/SharpLsp

NuGet browser: finish post-install sidecar workspace reload + prerelease/restore polish

Open
#123 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

cluster:nuget-pipeline
Dominant language
TypeScript
Stars
132
Forks
5
Avg merge
6h 24m
Merged PRs (30d)
27

Description

Tracking the remaining items from the now-deleted docs/plans/NUGET-BROWSER-PLAN.md (the NuGet browser feature itself has shipped; its design lives in docs/specs/NUGET-BROWSER-SPEC.md).

Functional (not yet done):

  • On a successful sharplsp/nuget/install, notify the sidecar to reload the workspace (the project file changed).
  • On a successful sharplsp/nuget/uninstall, notify the sidecar to reload the workspace.
  • Prerelease version toggle in the browser UI.
  • NuGet restore command + auto-restore on project load.

Deferred polish (explicitly low-priority in the old plan):

  • Cache sharplsp/nuget/* results keyed by workspace root + dir mtimes.
  • $/cancelRequest plumbing to kill in-flight dotnet restore children.
  • LSP-process install-latency benchmark (<150ms) in a perf suite.
  • Notification-ordering e2e (needs server→client notification capture in the test client).

The CSDEVKIT parity plan still tracks the user-facing NuGet items (prerelease toggle, restore) under "P2.4 / NuGet Package Management".

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with docs/specs/NUGET-BROWSER-SPEC.md and the sharplsp/nuget/install and sharplsp/nuget/uninstall entry points. Use the CSDEVKIT parity plan to review the prerelease toggle and restore requirements, then inspect the existing sidecar, caching, cancellation, performance, and notification tests if present. Done means the functional and explicitly deferred checklist items are implemented and verified.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend-api-design, developer-experience, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.