Document package dependencies

[Clindbergh]

It seems a good idea to document why certain packages were added.

Thanks for this innovative solution!

[strdr4605]

Isn't it clear from the usage of the package why it's added?🤔

[Clindbergh]

It depends. A couple of reasons why it might be helpful:

• A package might be used only for direct usage with the cli (without npm scripts)
• A package might be used in the code but usage search is not easy, for reasons which might be more or less common:
  • Packages might be added before they are actually used
  • The usage might be deleted but somebody forgot to remove it from the packages
  • The package might be used in a git submodule
  • The package might be used in generated or otherwise external / dynamic code

The main problem this feature would solve is the inability to add comments to the package.json.

This feature would allow the implementation of a CI rule that forbids the addition of undocumented packages, in a similar fashion that npm check allows.

[strdr4605]

Ok, let's suppose that some teams need this, what should be the API?
npx why --dep express?
npx why --dep express "our nodejs server".

Or maybe using the same convention as when installing packages.
npx why --S express "our nodejs server"

[Clindbergh]

I think devDependencies should be supported as well. They might even be more important.

How about

npx why script <script name> (alias for npx why <script-name>)
npx why dependency <dependency>
npx why dependency --dev <dependency> (or alternatively, but less preferred npx why devDependency <dependency>)

The API to add documentation would be just like with scripts (adding the additional string).

I prefer using full names as this is more intuitive for newcomers. Once #6 is implemented verbosity should not be a problem.

[Clindbergh]

Ideally any abbreviation of the words would work, similarly to some other cli tools like nmcli.

So npx why script == npx why scri == npx why s and npx why dependency == npx why dep == npx why d.

[tylercraft]

+1 to this feature request. When an app is large enough, with a lot of packages, it's not always easy to know why a package was added (or what edge cases to test when evaluating if we should update said package).

[strdr4605]

Ok, we can add this feature. Of course, it would be nice to implement also #6.

And I think as an API we can use:

npx why dependency react, npx why devDependency typescript, npx why peerDependency react-dom.

Also, if someone wants to work on this, we can discuss it here, and I will be happy to help develop and release this feature.
Or I will check it myself when I have time.