-
-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing prettier_print dependency #1232
Comments
@kddnewton Any time to take a look? |
I just found
This is a bit bad, it was working without ruby dependencies on v2 AFAIK? 😅 |
Hey @JounQin, I completely agree with you concerning those extra gem dependencies being required for the NodeJs formatter. Some deliberate choices have been made to use these in For me, I've added those gem dependencies to the Here's the wrinkle ... add a tool like ASDF to your development toolset. It manages all the different versions of Ruby that I have to have installed on my developer asset because I maintain numerous Rails projects that are on different versions of Ruby. As long as I run the The minute I bring VS Code (my IDE of choice) into the equation, it has a hard time formatting with prettier with this setup and I can face some timeout issues (see #1228). I actually have to make sure that these extra gems ( Anyway, I probably butchered this explanation and use-case. I do feel that it is very brittle to depend on Ruby gems whilst formatting from NodeJs' I don't have a terrific solution, I'm just sharing my use-case. I love the prettier project and look forward to helping us overcome these small challenges. |
@nadnoslen I too use asdf - my workaround for the env situation is to run In fact, I was having timeout issues, and I think I've confirmed my suspicions. I had initially started vscode from another project, and I had forgotten about it. After exiting vscode completely and running I haven't looked into this (or even searched issues here) but I did have several prettier-ruby server processes that survived after exiting vscode and were sucking a ton of CPU. Probably some weird circumstances there, I'll look into it if it happens again. |
Hi @nadnoslen @keithlayne I too use asdf but with Emacs and I am experiencing similar issues. I don' t fully understand this part of the README:
I probably fall under the "not already using prettier" category but
|
Depends on the editor, and how prettier is integrated. Prettier is JS, so npm is a natural way to provide a plugin. Note that the latest version of this plugin requires some gems no matter what, so this may confuse the issue of which install to use. Re asdf, there's an issue over there (asdf-vm/asdf#1178) about interaction between asdf and vscode that may be worth tracking for anyone using both. I'd expect any issues relating to asdf with emacs to be a lot easier to fix. Also...I seem to have gone way off-topic for this issue. Sorry about that. |
Okay friends, let me share some context and attempt to shed some light on what's going on. For a long time I was maintaining a parser in this project as a single Ruby file. It was very difficult to maintain, but that was the direction I started in so I rolled with it. It worked, but had a bunch of bugs, because it was super difficult to test from the Ruby side since you had to invoke node in order to run the formatting. A while ago I decided to rewrite the whole business in Ruby. The Ruby Association sponsored this work to build a standard library formatter, which resulted in Syntax Tree. That project is fully idempotent against every Ruby file I can possibly find. It's incredibly well tested, and is basically a much better version of this plugin. Furthermore, it handles a couple of things that prettier actually straight up can't with their current printing algorithm (namely printing out line suffixes with different priorities, necessary for heredoc declarations with comments after them). All of this is to say, Syntax Tree is just a better formatter than the prettier plugin. So at that point I decided it would be best to drop the existing parser here and to integrate the whole project. That was what version 3.0.0 was about. It drastically simplified this setup and made it much more maintainable going forward. It also made it so that I could release formatting fixes and you wouldn't have to bump this plugin. This plugin is basically now just responsible for the communication between the node and Ruby processes. The only thing this plugin even buys you at this point is embedded formatting (for example formatting a Ruby codeblock within a markdown file). Everything else is just a less-efficient version of running Syntax Tree. I'm definitely aware there are issues with folks having to install gems. Install paths/Ruby paths/executable paths, especially when integrated with editors, are hairy as all hell. Here are a couple of suggestions/paths forward that I think are best:
Sorry for the trouble here folks. I know this thing is held together a little loosely and there are a bunch of dependencies. Cross-language stuff is hard. I'm going to close this issue for now and point folks to this comment, and also the bundling issue as I think that will resolve this. |
@kddnewton Thanks so much for the added context and indications of where this project is headed! Using |
Seriously, thanks so much for your hard work! Code that you don't have to format manually, or even think about how to format, is a godsend. |
Metadata
prettier
gem version: 3.1.2syntax_tree
version: 2.3.1Issue
I upgraded an app to the most recent version of the prettier gem this morning (v3.1.2), but running prettier raised an error because it was unable to load
prettier_print
.Updating the version of
syntax_tree
to v2.6.0 brought the new dependency along with it.Should v3.1.2 require
syntax_tree
2.5.0 or higher to make sureprettier_print
is included? Or does it make sense to addprettier_print
to the gemspec directly since its class is referenced directly inserver.rb
?The text was updated successfully, but these errors were encountered: