Adds yarn package resolution to build

[jasongrout]

References

Supersedes #6937

Code changes

One issue we see with alpha releases is that if we install an extension which does not explicitly target the alpha release, we end up with duplicate core packages. For example, installing ipywidgets for the last stable release (with dependency on say services ^4) into an alpha release (which has services 4.1-alpha0), we'll end up with two services versions, since the semver semantics says that 4.1-alpha0 does not satisfy ^4. This means that, even if ipywidgets requires no changes to work in jlab 1.1 (services 4.1), I still have to explicitly change the dependency to be able to install and test into an alpha release.

This actually is an issue with actual releases too - cleaning and building a new JLab can bump the minor version of a js package without the user being aware (if for example an addon requires an updated minor version).

Instead, this forces the yarn resolution to be the versions of the js packages shipped with the release (up to patch releases - we're making the concession here that automatic js patch release upgrades are fine).

We can decide to change these resolutions before the final 1.1 release. But at least for alpha releases, this allows an extension developer to install the current extension to test.

Backwards-incompatible changes

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[blink1073]

👍🏼

[blink1073]

@meeseeksdev backport to 1.0.x

[lumberbot-app]

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout 1.0.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 73fef64544380aa2c8661819d12b2fe8b69b4b91

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am 'Backport PR #6938: Adds yarn package resolution to build'

4. Push to a named branch :

git push YOURFORK 1.0.x:auto-backport-of-pr-6938-on-1.0.x

5. Create a PR against branch 1.0.x, I would have named this PR:

"Backport PR #6938 on branch 1.0.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.