-
Notifications
You must be signed in to change notification settings - Fork 460
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
Feature/use native npm #606
Conversation
namely start a node-server and rest-call into that node-server
due to missing package.json files
and improve http resource handling
- I'm a big fan of prettier, and use it a lot myself - But I don't want npm to be a must-have for Spotless devs - That is why we have a separate CircleCI job `test_npm_8`, which is the only one that requires npm
Great POC! This passes on my mac. Not sure why it's failing in CI, but you can run the |
Also on my mac working. I'll investigate what the problem in ci is exactly.
For that part I did not actually change anything in the way we do this. NpmInstall is executed in the constructor of the I was working under the assumption that the state would only be re-created when something in the gradle cache or the configuration was changing and so only then a new The Node-based rest-server is newly launched every time a formatter function is requested from the steps. But I feel this is the safest way to do it - although this slows down test-runs, because this is done for each test then. |
In a first check the problem seems to be in the target |
somehow the mavenRunner got stuck when there was no stdout/stderr output. Fixing implementation as to detect when that is the case and to simplify things actually read stdout/stderr within the actual main thread, not seperately spawned threads.
the problem appears to be that on unix, the node-serve call is spawning sub-processes. Subprocesses, however, are obviously not correctly terminated by the java ProcessBuilder-API. The current solution is to actively call the rest service and request a shutdown of the process from within the api and only fall back to ProcessBuilder api if that does not work.
I fixed the ci problems. It appears that the node-server-process spawns child-processes in linux which cannot correctly be terminated via the java ProcessBuilder-API. -> Current ci problems are upstream IMHO - one of the guava libs fails to resolve. Any ideas what's wrong there? To my point
Is that assumption valid or wrong? |
I tried it on a couple projects, worked great on mac & linux. On windows, I have one project that works well, and another that does not. I get:
and once that has happened, subsequent files fail with I added |
Correction! The problematic behavior is not windows-specific. I have a complex project which works on unix and windows, and a complex project which fails on unix and windows. The only difference is that unix manages to kill the node subprocess, but windows does not. I will try to recreate the |
Okay, the previous commit adds a file which shows the bug. If you run this in the gradle plugin, you get
So it's clearly operator error - I was using the |
This should now be correctly ending up in the gradle output after commit 2bc0464
I’m unclear why this happens. The node process should be terminated using the |
b11c751
to
89b99a4
Compare
89b99a4
to
0808fc2
Compare
8cbbb27
to
6993d02
Compare
73b6894
to
bc9410b
Compare
Great, I just tested and it's no longer leaving ghost processes around on Windows. The error messages make it easy to debug, and it's so great to have access to all the prettier community plugins! I made a few small changes to the changelog and readme. I think this is ready to merge, I'll let you press the merge button if you agree. Accepting the committer invite I just sent you involves no duties, only privileges. Mostly it means you can restart CI jobs if you think an issue is just flakiness. Happy to press the merge button for you if you'd rather not accept the invite, no worries either way :) |
This is great. I’m happy to accept the invite and push the merge button myself 👍 thanks for your (again) great support in implementing this change. 🙏 |
Here is my proposal to get rid of the j2v8 dependency by simply using node.js/npm natively to run the
prettier
andtsfmt
formatters. (We are already using it natively to run thenpm install
process anyway.)The node process is spawned and then contacted from within spotless using a REST-api. Let me know what you think...
This should fix #556