Security News
JavaScript Leaders Demand Oracle Release the JavaScript Trademark
In an open letter, JavaScript community leaders urge Oracle to give up the JavaScript trademark, arguing that it has been effectively abandoned through nonuse.
license-badger
Advanced tools
Builds a badge indicating your project's license(s) and those of its dependencies.
(see also licenses for dev. deps.)
license-badger does not currently support badge-creation for pnpm or Yarn
projects. It also currently requires a package-lock.json
file. See the
FAQ.
Build a badge indicating the licenses of your project's dependencies (dependencies, devDependencies, whitelist-bundled devDependencies, and/or your project's own license).
Here's a sample badge (see below on the format):
You can also opt to only show non-empty types:
This project allows licenses to be selected in several different manners.
Current license checking tools typically only allow checking dependencies
or
devDependencies
, or they allow checking selected packages without transitive
dependencies. This project allows you to check specific selected packages but
with their transitive dependencies.
You can also create a badge which combines whitelisted licenses (or all
devDependencies
) with the licenses in dependencies
.
The following section. gives more detail on the types and which can be combined.
packageJson
)This option if set will check the license
within the package.json
pointed
to by packagePath
(possibly also using name
and version
), where
packagePath
defaults to the current working directory.
This option can be combined with any of the options.
dependencies
(production
)This option gathers license data from all dependencies
in package.json
and can be combined with any of the options.
Note that if you do not want to check a licenseInfoPath
and only want
dependencies
checked, you need to specify an empty string for
licenseInfoPath
.
devDependencies
(allDevelopment
)This option gathers license data from all devDependencies
in package.json
and can be combined with the production
option. licenseInfoPath
will
not be used if this is set.
devDependencies
(licenseInfoPath
)Projects may wish to bring over third-party dependencies into their final distribution files and/or repo via a copy routine (e.g., one run upon dependency updates).
This license selection type is done through the argument licenseInfoPath
pointing to a JSON file (recommended as licenseInfo.json
at project root)
with an array bundledRootPackages
property indicating the devDependencies
that are bundled. It can be combined with production
but allDevelopment
will override this setting and include all devDependencies
instead.
This whitelist will determine which of your top-level devDependencies
you are bundling and uses this information to build a badge
showing the license types within your distribution, including those packages'
transitive dependencies (not including your own project's license) and
sorted by permissiveness (see below for more permissiveness degrees).
Projects may use this selection type to take advantage of npm versioning,
but instead of only deploying to clients that have the capability to install
dependencies
, they may wish to deploy to Github-based hosting services
(such as Github Pages) which normally wouldn't bring in node_modules
yet
can host static files copied into a repository which can be viewed in
browsers.
Other current solutions may not be desired because a project may not wish to be forced to either:
node_modules
and use actual bundledDependencies
,
creating a potentially very large repositoryThough this option is only recommended for tools and such because one might
otherwise miss transitive dependencies (dependencies of your dependencies)
that should also be included. But if you are sure you know the complete list,
including transitive dependencies, you can use the option completePackageList
,
a Map of package names (only available in the programmatic interface).
Adopts helpful categories of npm-consider (now a part of a separate and maintained license-types project):
"publicDomain", "permissive", "weaklyProtective", "protective", "networkProtective", "useProtective", "modifyProtective", and "uncategorized". We also add "unlicensed" (which is copyrighted or otherwise explicitly against reuse--rather than merely being currently unspecified), "custom" (for "SEE LICENSE IN") and "missing".
It might be worth bearing in mind that "public domain" is a reference to specific licenses which seek to enforce that general principle (otherwise, the principle of public domain does not automatically apply world-wide), so this should make sense as the first category.
It might also be worth noting that these categories are only rough and items in the same category do not substitute for one another, e.g., different "permissive" licenses still have certain requirements. And even the same license may have different needs depending on the project for which it was used--e.g., the need to preserve the copyright notice for each package and/or file.
npm i -g license-badger
license-badger --filteredTypes=weaklyProtective,protective --textTemplate \"License types (\\${licenseCount})\" --licenseTypeColor networkProtective=blue,s{white} -l test/fixtures/licenseInfo.json test.svg
It is recommended you add this to a package.json
prepare
script so that you have the
latest info reflected upon adding new dependencies (or use a
prepublishOnly
script if only wishing to update for releases).
There is also a helper which only takes one argument and returns:
get-license-type "license expression"
You may wish to use the likes of @hkdobrev/run-if-changed (with husky)
so as to check for package.json
/package-lock.json
changes and run
license-badger
to ensure it is being built against the latest dependencies
(and/or devDependencies
). (The package is also useful for ensuring your
local installation is auto-updated to reflect your project's latest package
lock.)
Some npm commands (npm audit fix
) might auto-add items to the dependencies
,
but if you use such a command, be sure to undo the change (and run tests to be
sure).
package-lock.json
) required?Due to deprecation
by npm
and lack of support by yarn
or pnpm
, we needed to replace the
_requiredBy
property which we were using to detect devDependencies
(though
we might be able to just avoid it since devDep. detection was intended to
check all anyways). See to-do below.
package.json
devDependencies
and
trace dependency chains ourselves to restore ability to avoid
package-lock.json
(as long as node_modules
structure was not changed
like with pnpm
);
npm ls --json --parseable --long --unicode --prod/--dev
?node_modules
, we should support
pnpm and yarn; need @pnpm/list
for licensee.js
replacement for
pnpm (for reading subpackages and obtaining license metadata); for Yarn,
need https://github.com/nodeca/js-yaml/issues/62 due to Yarn currently
building a yarn.lock
(at least against this repo) which cannot be read
by that parser.getLicenseType
to stop treating AND as
potentially getting stricter one (though each license is different,
at least with "permissive" or "public domain" which could normally
submit to the other type). Originally filed
https://github.com/delfrrr/npm-consider/pull/26, but now handling
internally.
May even have problem with "OR" per
this issue,
though this seems due to an outdated dep.completePackageList
map option as its template
option
is called:// UNTESTED
'use strict';
const getLicenseType = require('license-badger/src/getLicenseType');
const licenseMap = new Map();
module.exports = {
plugins: [
license({
thirdParty: {
output: {
template (dependencies) {
dependencies.forEach((dependency) => {
const types = getLicenseType(dependency.license);
types.forEach((type) => {
const set = licenseMap.has(type)
? licenseMap.get(type)
: new Set();
set.add(dependency.license);
licenseMap.set(type, set);
});
});
}
}
}
}),
// Making plugin here on the fly, but should expose to API
(() => {
return {
name: 'license-badger',
buildEnd () {
licenseBadger({
licenseInfoPath: '',
completePackageList: licenseMap,
textColor: 'orange,s{blue}'
});
}
};
})()
],
input: '...',
output: {
//
}
};
(MIT OR (MIT OR GPL-3.0))
, (MIT AND (MIT AND GPL-3.0))
,
or (MIT AND (MIT OR GPL-3.0))
; use for overwriting of license
mentioned above and for feeding current license and other licenses
for license badge creation.
bundledRootPackages
in
licenseInfoPath
/licenseInfo.json
; might adapt
rollup-plugin-licenselicenseeInfo.json
filesByLicense
to optionally overwrite
license
in package.json
eslint-plugin-jsdoc
to own repo and
use to search for @license
within files so as to be able to
overwrite filesByLicense
with dynamic infobundledPackagesByLicense
(and repeating filesByLicense
info), and
using licenseeInfo.json
's bundledRootPackages
(and optionally
default
)
licensee
info, e.g., to list on command lineunapproved
, nonApproved
, and especially manuallyCorrected
info in reports so users can know whether to report.<link/a rel>
mechanism to point
to a package.json
file. (Besides being easier to convert this
code base to work in this manner, would be useful to have a
formal mechanism for finding other meta-data and source
code.) Might have separate <link>
or rel
to distinguish
between a package with just JS code and server code?es-file-traverse
to be able to list licenses for files
actually in use.FAQs
Builds a badge indicating your project's license(s) and those of its dependencies.
We found that license-badger demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
In an open letter, JavaScript community leaders urge Oracle to give up the JavaScript trademark, arguing that it has been effectively abandoned through nonuse.
Security News
The initial version of the Socket Python SDK is now on PyPI, enabling developers to more easily interact with the Socket REST API in Python projects.
Security News
Floating dependency ranges in npm can introduce instability and security risks into your project by allowing unverified or incompatible versions to be installed automatically, leading to unpredictable behavior and potential conflicts.