[BUG] handle subdirectories when building relative link URLs

[johnemau]

What / Why

The problem is described well in the following NPM community post and PR

• https://npm.community/t/relative-link-in-readme-of-monorepo/3806
• feat: handle subdirectories when building relative link URLs #435

The package.respository.directory is not honored when generating URLs for relative paths in README.mds of NPM packages displayed on npmjs.org.

How

• n/a

When

• n/a

Where

npmjs.org package pages for example, any link on https://www.npmjs.com/package/hint/v/6.0.1#further-reading

Current Behavior

Links 404 because link does not include subproject directory path provided in repository.directory of package.json

Steps to Reproduce

Add a relative link to README.md of a package in a subdirectory of a monorepo and publish that package.

Expected Behavior

Relative links become fully qualified URLs to github subproject resource in monrepo.

Who

• n/a

The Fix

First the consumer of marky-markdown must be passed a package.json meta-data including the repository.directory, I could not find the source code for npmjs.org but I assume this is not the case today because lib/plugin/github.js treats package.repository as a string type, which does not match the example in the README.md.

- var repo = gh(opts.package.repository)
+ // Handling both `string` and `{ url: string }` types
+ var repo = gh(opts.package.repository.url | opt.package.repository)

https://github.com/npm/marky-markdown/blob/master/lib/plugin/github.js#L52

Next buildLinkUrl should use opt.package.repository.directory when building the fully qualified path:

- return prefix + path.join(repository.user, repository.repo, DEFAULT_REF, url.href)
+ // Just an example, `opt` is not in scope, refactor to pass in the repository directory,
+ return prefix + path.join(repository.user, repository.repo, DEFAULT_REF, opt.package.repository.directory, url.href)

https://github.com/npm/marky-markdown/blob/master/lib/plugin/github.js#L12

References

Related to #435
Related to #446

[johnemau]

Current workaround is to provide a fully-qualified URL to gihub in the README.md instead of using a relative path.