CONTRIBUTING mentions yarn link, which doesn't even exist anymore

[FauxFaux]

🐛 Bug Report

CONTRIBUTING.md tells us we can test the project by using yarn link. Unfortunately, yarn has been forced to a random commit of yarn 2, and yarn 2 doesn't even have the yarn link (no-args) syntax:

faux@astoria:~/clone% yarn --version
1.22.10

faux@astoria:~/clone% cd jest
faux@astoria:~/clone/jest% yarn --version
2.3.3-git.20201026.e34bf6c6

faux@astoria:~/clone/jest% yarn link
Unknown Syntax Error: Not enough positional arguments.

$ yarn link [-A,--all] [-p,--private] [-r,--relative] <destination>

(Also, top tip to save anyone else an hour of debugging: this yarn version ignores your ~/.npmrc, you must rewrite it for them.)

If you use the yarn 2 syntax instead, you instead get a resolution error about @yarn/test-utils, which does indeed not exist in the registry, and apparently yarn isn't smart enough to link it, either in --all mode or while trying to link just the cli (exactly the same output).

my-app% ~/clone/jest/.yarn/releases/yarn-sources.cjs link ~/clone/jest --all
➤ YN0000: ┌ Resolution step
➤ YN0001: │ Error: No candidate found for @jest/test-utils@npm:^26.0.0
    at ~/clone/jest/.yarn/releases/yarn-sources.cjs:2:335032
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
[...]

Expected behavior

Can someone who understands this yarn setup please update the CONTRIBUTING.md document with how to .. run jest from git?

[jeysal]

@SimenB I assume we should recommend running the Jest binary in the root via its full path?

[SimenB]

Yep! That's the way I've done it all along, I never had much success using link. So either node ../jest/packages/jest/bin/jest or ../jest/jest.

No candidate found for @jest/test-utils@npm:^26.0.0

That looks like a bug in yarn. The module is not published, but it is in the workspace. I may have inadvertently fixed that in #10738 by explicitly telling yarn to use the one from the workspace

[jeysal]

Yeah it seems the correct version specifier could fix it. If so, we could ideally mention both ways of running?

[SimenB]

yarn link sorta painful though as the yarn version is checked into this repo, so you need to launch the yarn from here but in the other CWD. Ditching the link instructions altogether seems easier?

[FauxFaux]

As a first time contributor (to many projects), especially ones with workspaces, my worry with not using link is that it would pick up random versions of random modules, and not get you the full "running from HEAD" experience, which I like to avoid. As it sounds like that is not the case, great!

I also have no particular love for link. In fact, I found two (2) yarn bugs trying to run it against our npm 6 project.

[jeysal]

I think we've always strived to make Jest work the same no matter where the executable is being run from so I think running the jest executable from the Jest repository clone in a totally different directory is something consistent with that goal that should work for every project using Jest, and if it does not we should fix that. So this is something we can IMO recommend.
As for link, I also can't spontaneously think of something that you can only do by using the linking approach. So I would be okay with dropping that and replacing it completely with the jest executable approach.

[xavierstampslafont]

I was able to yarn link after going in to packages/jest-cli and setting the version back to 1:

$ yarn policies set-version 1.22.10

It then worked in my test project by doing yarn link jest-cli

It's a little odd because the Yarn documentation seems to still be taking about version 1

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.