-
Notifications
You must be signed in to change notification settings - Fork 82
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
Add support for formatters locally installed via yarn 2+ pnp mode #200
Conversation
Trying this out, I see that the In my experience, the existence of |
I added the version check because I ran into a problem with emacs invoking an outdated system version of yarn instead of the project local version, but I'm fine with leaving it to the developer to make sure they've got their external toolchain in order :) |
Sorry it took so long, but take a look at the latest commits I pushed to your branch. This introduces a new approach which provides full PNP compatibility while adding essentially no overhead (PNP-installed Prettier runs in 148ms with my version, versus 285ms when running via Yarn, versus 115ms when invoking the binary directly). |
And CI is broken, because of packaging bullshit. I guess I'll have to fix that too, will do either today or later... |
Excellent! I was noodling around with a special case of this that would call node directly instead of through yarn, but only for prettier. The more general approach here is very nice. I've also pondered spinning up a node process with prettier loaded, and then calling the api to do the formatting, thus sparing the user the overhead of loading node every time... but that's a project for another day ;) |
Currently working on getting this running in a project with a |
Filed prettier/plugin-ruby#1392 upstream about the remaining CI error. |
Getting back to this, with a few notes:
|
…with other formatters
I needed to add minor fixes to apheleia-ft.el to get CI working; will extract those into a separate PR if the yarn-pnp stuff needs more work after review |
Hmm, dunno about .js versus .cjs, when I ran yarn pnp locally it generated .pnp.js so maybe this is a version thing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was it intended to include these files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, those zip files are where the dependencies live
...or did you just mean the @types/emscripten dependency, specifically? I haven't tried removing that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me to write this in JavaScript if it is more robust, however having dependencies is not so nice - what leads to the requirement to find formatters in zip files? When would that be usable?
|
Yarn's pnp mode caches package zip files and reads them as needed instead of caching the unzipped files. A package can suggest that it should be unplugged (unzipped) via the |
What does |
I've extracted and cleaned up the pnp-bin js script; it's set up to build a minified standalone nodejs executable. The minified standalone is ~290k and targets node 8 or higher. Would it be better to use that here? |
Okay, yeah, that makes sense to me. If we at least have a standalone script, it's still not terribly nice, but at least the vendoring is restricted to a plaintext file. Thank you for doing this! I don't have any other major concerns about the PR. |
* When searching for an executable in node_modules, iterate through node's list of possible node_modules paths, provided by require.resolve.paths('') * Decide whether to use pnp or npm resolution based on the closest parent directory containing a .pnp.cjs file or node_modules directory, with a tie going to npm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
✨
You think we should merge this for now and then iterate from there? There are getting to be a fair number of issues fixed here but not on main. (I've given you admin permissions on the repository so you can merge things yourself) |
Sounds good to me, there's definitely been some creep in this PR (I don't see a PR merge button on my end btw) |
…mode (radian-software#200)" This reverts commit 54a192c.
radian-software/apheleia#200 seems to have broken prettier formatting
This adds support for formatters installed locally in project directories via yarn 2's "zero install" pnp mode.
It's quite similar to the support for formatters installed locally in a project's
node_modules
via npm, and leverages thenpx
symbol, so existing formatter definitions should work without modification.This checks for a
.pnp.cjs
file (expected in the project root for yarn pnp projects), then looks for a yarn executable, and checks the version of yarn to make sure it supports pnp. If that works, we just push"yarn"
onto the front ofcommand
.I've only tested this with a locally installed
prettier.js
. It's very much a works-for-me draft, I'm putting in a PR to make sure this is a workable approach before going any further with it.