Missing prettier_print dependency #1232

Activity

1. JounQin commented on May 25, 2022

   

   JounQin

   on May 25, 2022

   Member

   More actions

   @kddnewton Any time to take a look?
2. JounQin commented on May 25, 2022

   

   JounQin

   on May 25, 2022

   Last edited by JounQin

   Member

   More actions

   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? 😅

   👍React with 👍5Reacted by Daniel Nelson, Ezequiel Birman, David Alejandro, Matt Strayer and Rene Mercadel
3. nadnoslen commented on May 26, 2022

   

   nadnoslen

   on May 26, 2022

   More actions

   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.

   👍React with 👍2Reacted by Ezequiel Birman and Mark Li
4. keithlayne commented on Jul 8, 2022

   

   keithlayne

   on Jul 8, 2022

   More actions

   @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.
5. stormwatch commented on Jul 19, 2022

   

   stormwatch

   on Jul 19, 2022

   More actions

   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?
6. keithlayne commented on Jul 19, 2022

   

   keithlayne

   on Jul 19, 2022

   Last edited by keithlayne

   More actions

   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.

   👍React with 👍1Reacted by Ezequiel Birman
7. kddnewton commented on Jul 22, 2022

   

   kddnewton

   on Jul 22, 2022

   Member

   More actions

   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.

   👍React with 👍7Reacted by Keith Layne, Boris Petrov, Bryan Hoang, Cory Logan, adrian, Ryan Bates and Dave Nuttall

   ❤️React with ❤️8Reacted by Ezequiel Birman, Daniel Nelson, Mo Lawson, Jared Menard, Peter Krutz, Cory Logan, Alex Alves de Almeida and Ryan Bates
8. kddnewton

   closed this as completedon Jul 22, 2022
9. molawson commented on Jul 26, 2022

   

   molawson

   on Jul 26, 2022

   Author

   More actions

   @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. 👍

   👍React with 👍1Reacted by Ezequiel Birman
10. Petercopter commented on Jul 28, 2022

    

    Petercopter

    on Jul 28, 2022

    More actions

    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.

    👍React with 👍3Reacted by Ezequiel Birman, Cory Logan and Jorge Barnaby
11. stormwatch

    added a commit that references this issue on Jul 31, 2022

    Configure syntax_tree as formatter

    ...

    bfa6ed6