Option to include dev dependencies

[svenopdehipt]

It would be nice to have an option which would also include the development dependencies. The package does only include the runtime dependencies and doesn't have an option to change that behavior.

[tobysmith568]

Hey @svenopdehipt ,

This is something that has been requested in the past (see recently in #226), however we've delayed saying yes on those occasions because the authors of the issues weren't able to present us with reasons for why they'd like to include devDependencies.

It's worth noting that if you're using this package to fulfil the legal obligations of many open-source licenses that say something to the effect of:

"A copy of the license and copyright notice must be included with the licensed material."

or

"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

Then it's important to remember that this only applies to distributions of the licensed material. That's the key difference between dependencies and devDependencies for end products: You distribute your dependencies but you don't distribute your devDependencies.

That being said, we're very open to hearing about any other use-cases that you might have for our package where you'd require the devDependencies to be included; so please do let us know if you have one.

Thanks!

[svenopdehipt]

I would just have liked to have the option to include a third-party-licenses.txt in the GitHub repo which also includes the dev dependencies. This could be done with a cli flag, so that the old file can also be created.

[tobysmith568]

Hey @svenopdehipt,

Yeah I think we have a clear understanding of what it is that you would like. Our question now is more focused on why would you like it.

While this feature has been asked for before, no one has presented us with a practical reason for why devDependencies should be included. We ask because don't want to arbitrarily increase scope just for the sake of it - but we will consider it if there's a genuine reason behind it.

Would it solve a technical problem that you're facing? Is there a legal requirement you're constrained by?

Please let us know, Thanks :)

[www-chique]

In my front-end PWA web application, my files are bundled using Webpack (or Vite) to produce a bundle. Since all the code is bundled, it is recommended by those docs to include all my front-end dependencies as Dev dependencies. The production server doesn't need to have any information about those dependencies.

So I have this same issue like others. I'd like a CLI option to include Dev dependencies when generating the License file.

[tobysmith568]

Hey @www-chique ,

That's surprising to hear because that runs contrary to my understanding of how those tools work. Do you have a link to their docs where they suggest that so that I can do some deeper reading?

As of right now I don't see a correlation between bundling your production code and needing to declare them as devDependencies, so I'd be interested to know more.

Thanks :)

[tobysmith568]

Hey both,

I'm going to close this issue for now because I've not heard back from either of you. However, if you (or anyone else) has any input for how/why this feature might provide value to you then please do reply and we can open this back up.

Thanks

[AlexStormwood]

GitHub Actions built with JavaScript require the whole node_modules directory to be committed to an action's repository for it to be usable. While there are ways around that, they are not the default suggested way of developing an action.

This means that any action made that also has dev dependencies in it will be shipping dev dependencies to any action users.

You can read about this here:

• Docs on creating actions with JavaScript: https://docs.github.com/en/actions/creating-actions/creating-a-javascript-action#commit-tag-and-push-your-action-to-github
• Discussion from 2020 about how it's weird that we need node_modules to be committed to action repos: https://github.com/actions/hello-world-javascript-action/issues/12

This means that there are years of actions out there that are shipping dev dependencies to people. Weird or not, if they were to license all of that correctly then dev dependencies should be included.

[AlexStormwood]

Additionally, it would help simplify the automation of crediting & copyright notices in projects when we choose to credit everything.

I'm working on a game built with Electron, but because Electron is 99% dev dependencies, no one would know. Literally one dependency ("electron-squirrel-startup") compared to 11 dev dependencies. Doesn't seem right to not credit the Electron packages in a project like this.

[tobysmith568]

Hey @AlexStormwood,

Thank you for adding some more context to this thread.

As weird as JavaScript-based GitHub Actions are to distribute, they actually require no additional effort from the developer to ensure they're distributing the licenses of their dependencies. This is because when a developer commits the node_modules directory, they're also committing the license files within that node_modules directory. Because the license files are already distributed, there are no additional actions required by the developer.

That being said, your point about wanting to credit packages is an interesting one. So far, this CLI/library has only been focused on the legal compliance required by some OSS licenses.

If you're looking to use this package to credit all your dependencies, then that's a feature we're willing to integrate. However, before we open this issue back up, we'd like to hear a little more about your expectations for how you'd like this to behave.

Currently, our output file uses the following repeating format:

The following npm packages may be included in this product:

- dep-a@1.2.3
- dep-b@4.5.6

These packages each contain the following license and notice below:

# License X

If the output were to also include devDependencies, then the statement "may be included in this product" would no longer hold true.

• Would you expect slightly different text to be used for devDependencies, perhaps something like "The following npm packages were used in the development of this product"?
• Would devDependencies still include their license content beneath (it's not needed after all)?
• If a package is not a direct dependency of your product but it is a child dependency of both a normal dependency and a devDependency, should it appear in the generated output twice (once for each type of dependency), or is it being included as a normal dependency enough?

Thanks again for helping out in this discussion.

[AlexStormwood]

Thankyou Toby, this is all really insightful - especially regarding GitHub Actions, never thought of it that way before!

Would you expect slightly different text to be used for devDependencies, perhaps something like "The following npm packages were used in the development of this product"?

Honestly, the default output of this package is not on my mind at all.

As long as I can determine licenses and their dependencies through library usage of this package then I'll be happy. I've tried a bunch of packages for this purpose in the last couple of weeks but this one seems to run the best and is the smoothest to use! Especially with the whole part of matching one license to multiple packages - that's super handy.

If you need more context on my usage of this package: I built a helper tool that wraps around this, and it generates license data in a JSON format that I can then use and display in custom ways with whatever front-end I end up using in a project. Currently I'm looking at data like:

{
  "directDependencies": [],
  "transitiveDependencies": []
}

Each of those keys is an array of objects containing the license and its dependencies. I just wanna add dev equivalents of those keys into that mix too.

I know it doesn't help with the "generate a license file from the CLI" angle of this package, but having all of this data available means that anyone can make further choices about the presentation of that data to suit their own needs without a fuss. Happy to go further into this if needed, but really I just need the library usage of this package.

Would devDependencies still include their license content beneath (it's not needed after all)?

If licenses don't need to be shown for dev dependencies, that's cool - but at least having the data there gives people options on what they can do. Currently, this package provides no data to work with regarding dev dependencies, so no one can make any choices about what to display.

If a package is not a direct dependency of your product but it is a child dependency of both a normal dependency and a devDependency, should it appear in the generated output twice (once for each type of dependency), or is it being included as a normal dependency enough?

I think this again comes back to "if the data is there, we can make choices about it whenever we need to do so". But for the purposes of generate-license-file -- as someone without much legal knowledge, I would err on the safe side and show the license in all places that seem relevant.

[davidcann]

In the Svelte ecosystem, it's common to include most packages as devDependencies because Svelte is a compiler rather than a runtime. It uses vite to bundle everything for distribution. This seems like a clear reason to have the option to include devDependencies.

[tobysmith568]

Hey @davidcann,

Thank you for adding more details to this conversation.

You seem to be in a very similar situation to @www-chique above. In both situations there seems to be a misunderstanding somewhere around the impact of using a compiler/bundler/toolchain.

It is our understanding that using such tools has no impact on where a dependency should be listed. As I suggested to them at the time, if you're able to link to any documentation produced by the Svelte or Vite teams (or others like Webpack, Parcel, Rollup) that suggests you should list runtime dependencies as devDependencies then we'll be happy to look further into this use-case.

Thanks

[davidcann]

Hi @tobysmith568,

Using devDependencies is actually the default with SvelteKit. When you run npm create svelte@latest, it generates a basic project based on the following package.json, which has everything in devDependencies: https://github.com/sveltejs/kit/blob/main/packages/create-svelte/templates/default/package.json

Regardless, I created my own custom script based using this package's js API that combines devDependencies and dependencies, plus some custom formatting. That's a great option for anyone in my situation! Thanks for your work.