Packages language server

[AbdulrhmnGhanem]

Moving the discussion from discourse here.
I considered your suggestions and probably a custom editor will be the best fit for this purpose.
This is just a rough implementation; the UI, search, and installation aren't done yet.

Here's a quick demo of the current state.

I think it's possible to get this done before GSoC and allocate different ideas to the GSoC period, yet I need your input to form the proposal.
Pinging you once again, @davidanthoff @pfitzseb 😁

[AbdulrhmnGhanem]

I couldn't figure out what is the formatting tool, the editor rewrote package.json and package-lock.json completely.

[pfitzseb]

This is pretty cool! I still think code lenses would be nicer because they don't hide the actual Project.toml's source from the user, they simply add a few buttons/some additional info. What I had in mind is e.g. adding an input for each package under the deps header that allows you to specify the versions (and makes suggestions), or one that allows to add a dependency by name only. Stuff like that.

One more somewhat related issue is #2081 (that could be a stretch goal maybe?).

Re GSoC: It's up to you whether you want to submit an application for this idea or something else -- we'd be glad to have your help either way. Do you have any ideas for alternative projects? Maybe the open issues/some stale PRs could be an inspiration.

[AbdulrhmnGhanem]

still think code lenses would be nicer

I found the Go extension is doing that. I will try a language server.

One more somewhat related issue is #2081 (that could be a stretch goal maybe?).

This depends on the state of static analyzers for Julia, probably will need to extend the StaticLint.jl. Though I am ok with a challenging project.

Maybe the open issues/some stale PRs could be an inspiration.

My thoughts are that you are more aware of what is most important and significant regarding the current state of the extension.

[pfitzseb]

https://marketplace.visualstudio.com/items?itemName=pflannery.vscode-versionlens also has cool functionality, in case you haven't seen it already.

[AbdulrhmnGhanem]

Is there any endpoint that provides the packages' data? I haven't looked at pkg internals yet.

[pfitzseb]

Well, what info are you trying to get?
In general you should be able to extract all necessary data from the registry directly.

[AbdulrhmnGhanem]

In general you should be able to extract all necessary data from the registry directly.

This one https://github.com/JuliaRegistries/General?

Update:
Uh, I looked into the Pkg.jl and realized you probably meant Pkg.Registry.registry_info here. It's good that I have asked, I was about to make a silly mistake 😅.

I will try getting the codelens to work with some dummy data then integrate it with Pkg.Registry.

[AbdulrhmnGhanem]

So, Pkg.Registry.registry_info isn't part of the public API for Pkg.jl, is there a workaround for this?

[AbdulrhmnGhanem]

@pfitzseb, I am stuck on this. Any hints would be helpful.

[AbdulrhmnGhanem]

Closed this in favor of #2373; turned out what was needed has nothing to do the work here.