Skip to content
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

Closed
molawson opened this issue May 17, 2022 · 9 comments
Closed

Missing prettier_print dependency #1232

molawson opened this issue May 17, 2022 · 9 comments

Comments

@molawson
Copy link

Metadata

  • Operating system: macOS
  • Ruby version: 2.7.6
  • Node version: 14.19.1
  • prettier gem version: 3.1.2
  • syntax_tree version: 2.3.1

Issue

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 sure prettier_print is included? Or does it make sense to add prettier_print to the gemspec directly since its class is referenced directly in server.rb?

@JounQin
Copy link
Member

JounQin commented May 25, 2022

@kddnewton Any time to take a look?

@JounQin
Copy link
Member

JounQin commented May 25, 2022

I just found

You'll also need to add the necessary Ruby dependencies. You can do this by running:

gem install bundler prettier_print syntax_tree syntax_tree-haml syntax_tree-rbs

This is a bit bad, it was working without ruby dependencies on v2 AFAIK? 😅

@nadnoslen
Copy link

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 prettier/plugin-ruby and I get a sense that it is going to create a number of complications.

For me, I've added those gem dependencies to the :development & :test group of my Rails Gemfile. I've got the latest prettier/plugin-ruby in my Rails project's package.json. From my command line, I bundle install and yarn install to get all the libraries in order. From there it is easy to run prettier --check . & prettier --write . from the command line with this setup.

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 prettier commands from my command line, from my project root, with this setup it works great.

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 (bundler prettier_print syntax_tree syntax_tree-haml syntax_tree-rbs) are all installed on my global version of Ruby ... which might not be the same version of Ruby that my project is using (as a result of ASDF) thereby not leveraging the prettier dependency gems I added to my Gemfile.

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' prettier. I get a troublesome feeling when I see a tool needing libraries from multiple sources (gem versus npm).

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.

@keithlayne
Copy link

@nadnoslen I too use asdf - my workaround for the env situation is to run code . from the shell so that vscode inherits the environment. I suspect though that if you already have vscode open it will just open a new window, and will have the same env that it was started with.

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 code . in my ruby project dir, prettier-ruby worked fine.

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.

@stormwatch
Copy link

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:

If you're integrating with a project that is not already using prettier, you should use the Ruby gem. Otherwise you can use the npm package directly.

Note that currently the editor integrations work best with the npm package, [...]

I probably fall under the "not already using prettier" category but

  1. What are the actual benefits of using the npm package when a project is already using it? Is it just to avoid installing an additional gem? Is it to avoid using different prettier versions which might present inconsistencies?
  2. What does it actually mean for the editor integrations to "work best"? I think I could just install the gem and configure Rubocop accordingly. Would I be missing something?

@keithlayne
Copy link

keithlayne commented Jul 19, 2022

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.

@kddnewton
Copy link
Member

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:

  1. Drop this plugin, use syntax tree instead. Seriously, this is my number 1 recommendation, and I think it's for the best.
  2. Ensure all of the right dependencies are on your system for this to run and that everything is accessible. That means the node and ruby executables, the prettier and @prettier/plugin-ruby node modules, the syntax_tree, syntax_tree-rbs, and syntax_tree-haml gems along with their respective dependencies, and optionally (but recommended) a netcat executable like nc.
  3. Help me by looking at Bundle everything into the npm module #1260. That issue involves bundling everything into the npm module, which will mean it will ship everything necessary along with the JS.

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.

@molawson
Copy link
Author

@kddnewton Thanks so much for the added context and indications of where this project is headed! Using syntax_tree is fantastic for my use-case in Ruby-only projects and #1260 is really intriguing for projects already using NPM. 👍

@Petercopter
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants