Vscode-ruby: Is this project going to be maintained?

[ilyadh]

Ruby support in VS Code is still pretty poor, which is unfortunate. And there was no visible progress for about half a year now.

[orien]

Perhaps adding more maintainers will make the project stronger.

[wingrunr21]

I've pinged @rebornix to volunteer to help maintain the project

[meddario]

Any news? It's a pity that this project is stagnating

[wingrunr21]

No. I contacted him on Twitter and he said he'd take a look.

[wingrunr21]

As @rebornix is non-responsive, I've forked the project and will be publishing the extension under the name ruby-lang. I'll be happy to merge things back into this project if it starts to be maintained again.

I'm running through my own PRs right now and merging them into master. I'll be asking if other individuals who have opened PRs against this repository would like to reopen them against my fork.

https://github.com/wingrunr21/vscode-ruby-lang

[g-arjones]

152 is particularly cool, IMO...

[rebornix]

Hi here, sorry for being not responsive lately. I took paternal leave from Sept and came back before Christmas and then worked on new buffer implementation in vscode https://github.com/Microsoft/vscode/pull/41172 during the last month. I'm not trying to find excuses but diaper duty does take most of my personal time (even though I work on Code, this extension is not an official one).

I want to say Thank You to @wingrunr21 for reaching out and trying to help. I'm open to having more maintainers, we can start from triaging issues, reviewing and merging PRs, and finally being one of the publisher of this extension. I'd like to merge @wingrunr21 's closed PRs if he is still Okay with that and wants to help. Splitting the community is the last thing I want to see and I'll try my best ;)

Lastly I want to thank you all for being patient, this extension and ruby support can be definitely improved in many ways. Whenever I looked at Go, Python or Vue extensions, I always thought hey we can do similar things in Ruby ext as well, but as I don't write Ruby daily so they sit sadly in my backlog. It would be awesome if we can see more inputs from real ruby programmers, and draw the roadmap for this extension together.

[wingrunr21]

Sure, totally fine reopening PRs and putting things back here.

We just need to make sure there are some maintainers on the project regularly. Some of the outstanding issues here make using the extension pretty annoying if you DO write Ruby every day.

[rebornix]

@wingrunr21 I lost the chance to merge your PRs back as those branched were deleted. Do you mind filing a PR which includes those changes? Or maybe I can simply do a cherry-pick.

[wingrunr21]

I can reopen them later tonight

[wingrunr21]

Ok, they should all be reopened. I also rebased them against current master of this repository so they should merge cleanly

[rebornix]

@wingrunr21 thanks for the rebasing, it makes the merging really easy and fun. Thanks again for all your contribution.

[orien]

@rebornix congratulations!

[adrianpacala]

@rebornix thanks 💜

[perlun]

Thanks all for your effort. @wingrunr21, I noted your fork is now gone - are all the changes back into the mainline repo nowadays?

I see that there are a few changes in master since the 0.16.0 release, so it would be nice to get a 0.17.0 version out with these if possible.

[wingrunr21]

Yes, all fixes are now back in this repository.

@rebornix should be able to publish a new release

[morgancurrie]

Any ETA on when we can expect 0.17.0? Our team has been doing the downgrade to 0.15.0 trick to get around issue #251, but would love to turn auto-updating back on for our other extensions!

[rebornix]

@wingrunr21 any possible that we can have a fix for #251 ?

[wingrunr21]

I’m planning on taking a look this weekend

[gurgeous]

How can we help? A few suggestions for the maintainers:

• add a CONTRIBUTING section to the README
• aggressively close existing issues, or declare issue bankruptcy and move on

I'd love to start submitting PRs, but I don't want to pile on...

[wingrunr21]

Right now it is digging out of the hole. I haven't been as active the past week or so due to client launches at work. I'm hoping to dig in and start triaging again soon (like today).

As for issues: I'm somewhat of the opinion that all issues that were opened prior to last August should be closed and reopened if they are still a problem. There's a lot of duplicates.

263 would be great for other commentary. It's loosely turning into what direction should this extension take and user commentary on that would be beneficial

[wingrunr21]

@rebornix once #279 is reviewed/merged we should be good to go

[rebornix]

@wingrunr21 0.17.0 released. Your commit messages are descriptive and can be used directly as changelog, thanks!

[gurgeous]

Let's revive this conversation - I think we have plenty of volunteers willing to pitch in. How can we help? Should we add maintainers? Give us some homework and we can move the ball forward! :)

[wingrunr21]

I need to get some time to dive back into things.

1) The biggest help would be triaging issues. There are a ton of dups and outdated issues.
2) Documentation

After that, I've been working on addressing some fundamental issues in the extension behind the scenes:

• the current regex based code folding/highlighting solution is simply too brittle. Ruby is too dynamic to catch every syntactic variation
• Linting needs to occur out of band with the primary UI thread. While farming this out to a language server is probably the best solution for a rich linting experience, IMO the extension needs to support some kind of linting out of the box

I am working on improving the extension. However, the exact same issues keep getting raised over and over with minor variations, even after things are fixed. That to me points to some fundamental issues I'm trying to address. These things take time. I'm only able to work on this in my free time and this isn't my only open source project.

[gurgeous]

Don’t feel bad! I (and everyone else) appreciate all your hard work. Find ways to let us help. Can you deputize me or castwide to pitch in on github issues? I am between projects and I have time to pitch in at the moment. Won’t last forever. :)

My typescript ain’t bad and I wrote my own extension now, so I’m feeling confident about making decent contributions.

Happy to discuss folding & linting improvements too if you want feedback or help.

[perlun]

While farming this out to a language server is probably the best solution for a rich linting experience, IMO the extension needs to support some kind of linting out of the box

The language server can be provided by the extension though. Look at RLS and what the great Rust people have done with the Rust extension for VSCode during the last year or so. It's an _incredibly nice_ experience getting started with Rust in VSCode these days; you just install the extension and allow it to install the Rust Language Server etc. and... off you go!

I think in the long run, definitely: we should have a language server for Ruby also, and it should probably be written _in_ Ruby also. This project exists, I have no idea if it's good or not.

[wingrunr21]

@gurgeous I don't have repo level permissions so no, sorry. If @rebornix can add you great.

@perlun Yes, that's how the eslint and tslint extensions are implemented. I was exploring that approach for sure. But, remember that most other languages have a defacto linter. Ruby has several that are in common use (reek, rubocop, bundler-audit, etc). There's no such thing as "off you go" in Ruby. We need to support bundler, we need to support gemsets, multiple version managers, monorepos with multiple Gemfiles, etc. It is not ever going to be as simple as Rust.

What I meant by my comment is that for the time being I'm focusing on the core language experience in the editor. That means I am not looking at things like symbol definitions and intellisense. The parallel work with Solarized is focusing on this.

[gurgeous]

@rebornix - Can we add more maintainers to the repo?

[wingrunr21]

k, I just went through and mass-closed issues. I also updated the v1 milestone. I'm going to try and put together issues/roadmap for v1 so that people can track progress.

As I create the milestone issues, I'll be linking to any issues (open and closed) that pertain to those milestones.

Just to be super transparent: this milestone is not going to turn VSCode into RubyMine. I want to make sure things like highlighting, debugging, code folding, linting, version managers, etc work correctly before we start talking about other features.

[thomthom]

Is it ok to reopen issues which are not resolved?

[wingrunr21]

I'd prefer you did not. I'm guessing the vast majority of the issues I just closed are probably still issues.

[thomthom]

Ok.

So, I understand that larger changes are planned - which is the priority. They may or may not resolve current issues. Will it be possible to log new issues at some point?

Will this repo be open to PRs?

I'm wondering because one of the open issues related to breakpoints while debugging. Which is making the debugging a challenge at times. Curious to whether it would be any point to dig deeper into it. Or whether to hold off any work for the time being.

[wingrunr21]

Yes, I don't want people to stop logging issues. However, the sheer quantity of open issues (many of them potential duplicates or based on the same underlying flaws) made it difficult for users to discover open issues and for contributors to figure out where a certain issue was located.

I'm more or less scrapping the vast majority of the code currently in the extension. I've tried several times to fix some of the recurring bugs here and every time it appears to fix one thing while breaking 2 others. Without a well architected and tested structure, I don't think it's possible to cover all the dynamic use cases Ruby devs have. I realize some of this is cryptic but I'll have a PR up soon demonstrating my basic plan of attack here.

I plan on continuing to support at some level the existing functionality in the extension and gradually moving features over. However, I'm not going to spend considerable time fixing bugs in the existing codebase. If PRs are submitted against the existing code base I'll merge them though.

I'm pushing to get a baseline structure in place for how I think the extension needs to move forward. From there, people will be welcome to submit PRs to try and accelerate the timeline. I'll be setting up CI to build nightlies of the vsix file so that people can use this workflow to install the extension.

[perlun]

@wingrunr21 Thanks for the transparency, much appreciated. While mass-closing issues can cause a bit of churn, I understand the _reasons_ for doing so much better now after you explained. I strongly appreciate you doing this in the "open", in bazaar-style, instead of the more closed "cathedral-style" which some FOSS projects use and have used historically.

Bottom line: "be patent, we will hopefully have a much better baseline in the future; fixing all bugs in the current implementation is hard/impossible, so we will not waste time doing so but instead focus on the rewrite". I fully support this move. 👍

[thomthom]

Thanks for clarifying. Looking forward to seeing where this is headed.

[wingrunr21]

Yes, thanks everyone for their patience. I really do want this extension to be a really solid option for people within VSCode.

[wingrunr21]

Ok all,

Milestone issues are opened and have TODO items within them (see the v1 milestone). If there's specific commentary/feedback on those roadmap items please put them in the associated issue.

I am going to close this issue now. We can continue talking here but I think the overarching reason this issue was opened has been addressed.

I'm hoping to finish prepping a proof of concept PR and open that tomorrow AM for the language server support.