Closed luke-lacroix-healthy closed 2 years ago
When switching from using the 'package-lock.json' as a source of information about the installed packages to using the 'node_modules' directory, I did not mimic the complete node package resolution strategy. I simply used the 'node_modules' directory of the 'package.json' under inspection.
So I think the best way to support monorepos is to look into the 'node_modules' of the directories up to the root directory too (and check not only the name of the package, n´but also the version number).
I'm afraid that this will take some planning, so give me a little time to do it 😄 .
@BePo65 That certainly sounds better. Thanks!
I just merged a pull request that should solve this issue. I added some tests for it, but I don't have a real world example at hand.
@luke-lacroix-healthy : Would you be so kind to make a short test with a real monorepo project using the master branch of this project (the pr is not published yet; I want to wait for your final ok)?
I'll try. No command line flag needed? @BePo65
No command line flag needed, as license-report now mimics the node package resolution algorithm: if a package is not found in node_modules, just step up 1 level up to the root directory and try it again.
It seems to be working correctly :)
I am trying to leverage this tool to generate the license lists for all the packages in a monorepo and have run into a few issues:
I think monorepo support could be added easily by either:
--monorepo
option: the tool would scan the sub-directories forpackage.json
files and resolve the locally installed package to either the value in it's nearest node_modules folder UP TO the root directory--add-node-modules X
option: the tool would scan these additional locations for module metadata