search

xz64 / license-webpack-plugin

Outputs licenses from 3rd party libraries to a file
ISC License
165 stars 51 forks source link

Test files getting picked up by the plugin #40

Closed johannao76 closed 6 years ago

johannao76 commented 6 years ago

We are having another issue where if we run the plugin on a dev build with karma enabled, "object-assign" gets added to the license output, even though this is a dev dependency and should be ignored (?). Output of yarn why:

object-assign"

=> Found "socket.io#object-assign@4.1.0" info This module exists because "karma#socket.io" depends on it. => Found "gulp-util#object-assign@3.0.0" info This module exists because "karma-remap-istanbul#remap-istanbul#gulp-util" depends on it.

=> Found "karma@1.5.0" info Has been hoisted to "karma" info This module exists because it's specified in "devDependencies".

=> Found "karma-remap-istanbul@0.6.0" info Has been hoisted to "karma-remap-istanbul" info This module exists because it's specified in "devDependencies".

xz64 commented 6 years ago

Any reason to use the plugin for a dev build? Typically this plugin would only be used for production builds.

johannao76 commented 6 years ago

We generate this file during the dev build so that developers know that they are adding an OSS dependency and can include this file as part of their PR. We have special rules to require an OSS approver for changes to the license file. Why wouldn't the above work? If it is a dev dependency, it shouldn't get picked up, right?

xz64 commented 6 years ago

Right now the plugin pretty much looks at any file webpack says was used in the build. Can you share some sample repository showing the specific issue with karma?

xz64 commented 6 years ago

Dev tools may inject their code into your bundle to support features like live reloading. The plugin just takes whatever webpack is reporting is used in the bundle. The v2 alpha ( https://github.com/xz64/license-webpack-plugin/tree/dev ) has a feature to exclude packages so you may use that