test: migrate infer-plugins-ext-dir test cases

[43081j]

Pulls the infer-plugins-ext-dir tests from prettier.

[43081j]

@fabiospampinato this one seems like something we should discuss/decide before we merge these tests

it seems prettier treats *.foo as if it was **/*.foo, whereas we treat it as ./*.foo

i think we're correct, but this means a whole bunch of prettier configs may fail with our CLI. maybe we should do a special case that transforms "*.ext" into "**/*.ext"?

[fabiospampinato]

Yeah I think so, no need to break the world here. The problem is that this is a bit tricky, what is the actual logic that we want? Worth checking what v3 is actually doing, because there are many potential ways to implement something like this.

I imagine we should try to explode the glob and do something with that in some cases 🤔

I think we can skip this test for now and fix it later if it's the only blocker for this test suite.

Is everything else basically just copy/pasted?

[43081j]

Pretty much, just the paths changed to the mock/fixture extensions. The rest should be the same

[fabiospampinato]

What's the blocker for this PR, interpreting *.foo as if it was **/*.foo?

[43081j]

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

[fabiospampinato]

So in order to select files actually matching *.js one has to write ./*.js?

[fisker]

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.

[fabiospampinato]

@fisker presumably it isn't worth changing this, right? 🤔 how it works currently just seems incorrect to me, if I'm understanding it right.

[fabiospampinato]

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

[fisker]

I don't understand "pick", are we talking about files in overrides?

[43081j]

Basically I think a non relative wildcard would be assumed to mean ./.

So internally:

• * becomes ./**/*
• *.js becomes ./**/*.js
• foo becomes ./**/foo
• ./* is left as is
• **/*.js is left as is (isn't a standalone single *)

That would be like prettier right now I think

[fisker]

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.

[fabiospampinato]

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?

[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

[fabiospampinato]

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

[43081j]

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

[fabiospampinato]

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 👍

[43081j]

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

[fabiospampinato]

Aaaaah yeah, ok I get it now, I'll fix this in worktank 👍

[fabiospampinato]

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.