Future of this library

[franciscop]

Hi everyone!

So this library has some issues right now as you might have found out. I've learned a lot since I created it a while ago, and I think I'm ready to give it a go at rewriting some of the core parts. What do you think of this?

• I've already tried a minimal build with check-licenses. It's definitely not as complete as legally (and that's why it's not replacing it), but I think it has a lot better experience and stability. If you just want a quick check for license count, for now please use that.
• Better module crawling. Right now legally is overfetching the modules that you might have, so you might be checking licenses that are actually not used. This is safe, just more work for you. This should not be like that though, it should just fetch the right amount. Example: if a library you use has a subfolder with a package.json, it'll also check the license of that even if it's not a proper project.
• Use package-lock.json by default if it's found. This strongly relates to the previous point.
• Dev vs Prod. Some people bundle and deploy their dev dependencies, some people don't. Allow the user to choose what they prefer to check the licenses for.
• Remove bundling. This was a mistake.
• ESM code like Sindre Sorhus explains here.
• Code cleanup. Issues related to import vs CLI keep popping up.
• Move from minimist to meow. It's 2021, I don't want to be dealing with CLI arguments semi-manually.

It seems this all (except the move to ESM) would be backwards compatible, so I can start working on some of these without doing a full rewrite.

[Tasketo]

That sounds really nice @franciscop! and it would speed up my builds a lot.
I agree with all the points.

Use package-lock.json by default if it's found. This strongly relates to the previous point.

Keep in mind that a lot of people also use yarn or other package-manager. So maybe keep the design open, when integrating the package-lock.json, so people can add support for different package-manager later.

Dev vs Prod. Some people bundle and deploy their dev dependencies, some people don't. Allow the user to choose what they prefer to check the licenses for.

Additional to dev and prod people may use private package, which should be ignored. Maybe support a denyList or similar. 150% solution would be the option to ignore the package and/or its dependencies. That's just an minor, but its annoying to check every time which packages are unlicensed.

Just to be sure: Keep the node-api, which does not exist in check-licenses.

[jojomatik]

• Better module crawling. Right now legally is overfetching the modules that you might have, so you might be checking licenses that are actually not used. This is safe, just more work for you. This should not be like that though, it should just fetch the right amount. Example: if a library you use has a subfolder with a package.json, it'll also check the license of that even if it's not a proper project.
• Use package-lock.json by default if it's found. This strongly relates to the previous point.
• Dev vs Prod. Some people bundle and deploy their dev dependencies, some people don't. Allow the user to choose what they prefer to check the licenses for.

These three points would really help me in my projects. Especially the last of them: currently to check prod dependencies only I have to delete node_modules, run npm install --only=prod and then run legally.

Are you still working on the topics in this discussion @franciscop?

[franciscop]

I haven't really worked on this, it requires few days of uninterrupted work only on legally and I haven't found the time/motivation for that so far. I believe a good start would be to create a find-dependency-folders package that lists all dependencies given a path (to the current project folder or a temp folder) and a dev: true|false flag, something very roughly like this:

import meow from 'meow';
import listDependencies from 'list-dependency-folders';

const cli = meow(`...`, { ... });

const deps = listDependencies(cli.input[0] || './', { dev: cli.flags.dev });
console.log(deps);