prettier
test: migrate `infer-plugins-ext-dir` test cases
What's the blocker for this PR, interpreting *.foo as if it was **/*.foo?
it should be good to merge and we can track the *.foo stuff separately
basically globs with no path are treated like **/{glob}. e.g. *.* is **/*.* in prettier. and *.js is **/*.js
So in order to select files actually matching *.js one has to write ./*.js?
I think treating *.js as **/*.foo idea comes from ESLint, but the link https://github.com/prettier/prettier/blob/de30788d30990b35534832ca554f5d5add2d4221/src/config/resolve-config.js#L105 is broken, so I'm not really sure.
@fisker presumably it isn't worth changing this, right? 🤔 how it works currently just seems incorrect to me, if I'm understanding it right.
@fisker random question, but if *.js is interpreted as **/*.js, how do we actually pick only the js files in the current directory? is ./*.js the answer?
Basically I think a non relative wildcard would be assumed to mean ./.
So internally:
*becomes./**/**.jsbecomes./**/*.jsfoobecomes./**/foo./*is left as is**/*.jsis left as is (isn't a standalone single*)
That would be like prettier right now I think
As I said, the files in override logic part is from ESLint, in previous ESLint config system(now it's called "Legacy config") it works the same.
Related code in Prettier core https://github.com/prettier/prettier/blob/0d10f1f846351274922cd205f1d4997206183151/src/config/resolve-config.js#L107
The comment in that file can also confirm the fact, though the link is broken now.
If I run the tests just for this I don't see it ever exiting (after a few minutes at least):
NODE_OPTIONS=--experimental-vm-modules npx jest --rootDir test/__tests__ infer-plugins-ext-dir.js --testTimeout 60000
Does this work for you, @43081j?
mentioned in discord too:
its because the worker exits successfully but worktank doesn't propagate this
that means we continue waiting for the worker even though it exited long ago
under the hood, webworker-shim does emit close events. so worktank should probably listen to those and pass them back to the caller
then inside the CLI, we can decide how to deal with it
its because the worker exits successfully but worktank doesn't propagate this
It sounds potentially like a bug on my end, but why is the worker exiting in the first place? 🤔
its because the worker exits successfully but worktank doesn't propagate this
It sounds potentially like a bug on my end, but why is the worker exiting in the first place? 🤔
because the plugin doesn't exist (which is what the test is testing I assume? I'll have to re-read them to be sure)
either way, its a valid case I think. plugin doesn't exist, so it exits with an error
Is it exiting from inside prettier/standalone or on our end? In my mental model prettier/standalone would never just force-exit 🤔 But I guess we should handle that, I think I missed this edge case in worktank, I'll update it 👍
it is our exit, not prettier's
when you call prettier (via prettier_parallel or serial), we call our own function to load the specified plugins
once we have those, we call prettier core.
but if the load failed, we exit
I've just pushed a new version of worktank (v3) that handles workers exiting themselves, among other things. In this case it would throw custom WorkerError that we could check against.
BUT, on a second thought I think it may be cleaner to just not exit where we are exiting, and instead just throwing a custom error, and then checking against that error and exiting then, from the main thread.