Packages using lerna are not distributed including LICENSE

[kylef]

Packages which are distributed with lerna are often do not include a LICENSE file, this makes consuming packages that use lerna tricky as the license file and copyright notice are not included in the NPM distribution. Tools such as license-checker won't be able to find the license file and respective copyright notice and author.

NPM would normally include files such as the LICENSE file in the NPM distribution. When running npm pack or such the license will be included in the created tarball.

Certain files are always included, regardless of settings:

• README
• CHANGES / CHANGELOG / HISTORY
• LICENSE / LICENCE
• NOTICE

From https://docs.npmjs.com/files/package.json#files.

The common pattern I've seen in libraries using lerna is that the LICENSE file is found in the root of the repository. Since lerna will publish each package in the package/ directory, the package inside repository doesn't contain a copy of the LICENSE.

You can see this in babel, the repository contains a LICENSE file, and package such as babel-runtime on NPM (tarball: https://registry.npmjs.org/babel-runtime/-/babel-runtime-7.0.0-beta.2.tgz) will not have any license file.

I am wondering if there is an automated way that this problem can be solved and the project LICENSE can be present in the distributed NPM tarball. Perhaps in lerna publish the license could be injected into the package?

[evocateur]

Would symlinking the root LICENSE file into the package roots work? (just checked with npm pack, nope 😞)

So yeah, either copy the LICENSE file into each root manually, or lerna can do it I guess. fstream-npm's implementation is probably "good enough" in terms of identifying if a root license file exists.

[honzajavorek]

It would be great if Lerna automatically dealt with this problem as it propagates to many packages using Lerna. Otherwise we who care about licensing need to go to every single monorepo maintainer and to ask them to add a custom mechanism to copy the licenses into the individual packages, which is, let's say, a long run.

[evocateur]

I don’t disagree, I just don’t have time right now.

…

On Feb 6, 2018, at 10:22, Honza Javorek ***@***.***> wrote: It would be great if Lerna automatically dealt with this problem as it propagates to many packages using Lerna. Otherwise we who care about licensing need to go to every single monorepo maintainer and to ask them to add a custom mechanism to copy the licenses into the individual packages, which is, let's say, a long run. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[honzajavorek]

@evocateur I think I can work on this. If you have any advice on what to do or where to start, let me know.

[honzajavorek]

My proposal would be:

1. Right before publishing the package, look whether there is a license present in the sub package.
2. If yes, do nothing. If not, look whether there is a license in the root package.
3. If yes, copy the license to the sub package, temporarily. On success or failure remove the temporary file.
4. If there is no license in the sub package nor in the root package, print a warning the published package is not going to be licensed properly.

[evocateur]

That sounds great, thank you! I would recommend an approach similar to how the prepublish and postpublish lifecycles are called in commands/publish/index.js: loop through all of the updated packages (`this.updates`) right before the publish method, letting you set up the bookkeeping necessary to preserve existing license files but clean up the temporary copies. Cleanup would be done all at once later when the publish loop resolves or rejects. The rejection cleanup should be sync, rethrowing the error so we don’t lose it, but the resolved cleanup should be async (joining the existing promise chain).

…

On May 28, 2018, at 07:59, Honza Javorek ***@***.***> wrote: My proposal would be: Right before publishing the package, look whether there is a license present in the sub package. If yes, do nothing. If not, look whether there is a license in the root package. If yes, copy the license to the sub package, temporarily. On success or failure remove the temporary file. If there is no license in the sub package nor in the root package, print a warning the published package is not going to be licensed properly. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[lock]

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.