feat(link): Use publishConfig.directory as symlink source if it exists to allow linking sub-directories

[kamranayub]

Description

This is a fork of #2081 but uses the suggestions from #2209 (comment)

• Use pkg.contents to resolve symlink source path, allowing usage of publishConfig.directory to link to a sub-directory
• Add support for --contents to bootstrap and link with docs

TODO

• Update documentation to mention semantics of directory with regards to link command

Open Questions

• ❓I believe this may be a breaking change, as anyone using publishConfig.directory and who've run lerna link before will experience a change in behavior. I could enhance this PR to include a flag for link, suggestions welcome.
• ❓ I'm unclear what the comment "And probably need to make the pkg.bin field resolvable from contents, as well (it's currently hard-code)" refers to. In the Jest snapshots, it looks correct for bin files (I think) but wondering if @evocateur had some more context for that comment that I should add to the PR.

Motivation and Context

Closes #2209

There was an existing PR already #2081 but it needed tests and I believe the idea was to use pkg.contents instead of introducing a new config property.

I explained my motivation/need in my comment (#2081 (comment)):

---

The publishConfig.directory works well for publishing. In our monorepo we have two packages, core and baked. baked uses components from core. Since we use Rollup + Babel + TypeScript (these are libraries), we have a dist directory that we publish as the package. While we can publish new versions of the core components, for local development we're looking at using lerna link to make that easier to have a nicer workflow.

In a file within baked you may have:

import { MyComponent } from '@org/core-components'

This works for a published package but since lerna link symlinks the root directory and not the dist directory, for local development you must change the path:

import { MyComponent } from '@org/core-components/dist'

How Has This Been Tested?

• Added Jest tests with snapshots that test the generated src/dest paths
• Linked lerna with npm link and tested within our own monorepo for our use case
  • Specifically I tested depending from package baked -> core and successfully consumed TypeScript-based components from the symlinked core package.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[evocateur]

Thanks for adding tests, they look good. A few more additions to make this "fully formed" and we're good to go.

[evocateur]

I don't see this as a breaking change, really. If one is already using --contents or publishConfig.directory, then this is somewhat of a "return" to expected behavior.

[evocateur]

Thanks so much! Just remove the unused with-contents fixture under bootstrap, and we're good to go!

[evocateur]

Thanks!

[evocateur]

Published in v3.17.0