How do I connect npm to Lodol?

Authenticate npm once from your workspace and every action and trigger it supports becomes available to drop into a workflow. There is no glue code to write or maintain.

All integrations

npm

Code Repositories

Look up anything on the public npm registry. Read a package's details, licence and maintainers, walk its release history, open one version for its dependencies and tarball, check what each release channel points at, search npm with its own quality and popularity scores, and track download counts by day, by version or against other packages. No account or API key is required.

Get Started Browse all integrations

11 actions

Actions

Steps your workflow can run in npm.

Get a packageLook up an npm package: what it does, who maintains it, what licence it carries, where its source and issue tracker live, which release channels it publishes to, how many versions it has, and when it was first and last published. This is the overview of the package itself; use 'Get a package version' for one release.

List package versionsList a package's releases with the date each was published, which release channels point at it, and whether it is a prerelease or has been deprecated. Versions are ordered by semantic version rather than as text, so 1.10.0 sits above 1.9.0 and a release sits above its own release candidates.

Get a package versionRead one release of a package: its description and licence, when it was published and by whom, what Node versions it runs on, whether it ships types or a command line tool, how large it unpacks to, and the tarball and integrity hash npm would install. Give a version number, or a channel such as 'latest', and the answer says which version that resolved to.

Get package dependenciesList what a release depends on as one flat list, each row carrying the version range and which group it came from. npm splits these across four fields keyed by package name, which a workflow cannot walk without knowing the names already, so this is the action that answers 'does this still depend on lodash?' in one step. Choose which groups to include.

Get release channelsSee which version each of a package's release channels points at right now. A channel, which npm calls a dist-tag, is what 'npm install package@next' resolves through, so this is the one-request way to answer 'has the beta moved?' or 'what does latest point at today?'.

Search packagesSearch npm and get back the matches with their weekly and monthly downloads, how many packages depend on them, and npm's own quality, popularity and maintenance scores. The search qualifiers are separate fields here, so filtering to one maintainer or one scope, or leaving out anything deprecated, needs no query syntax.

Get package downloadsCount how many times a package was downloaded over a period, as a single number with the per-day average beside it. Pick one of the standard periods, or set a start and end date for anything else. The answer names the days npm actually counted, so a partly covered period still reads honestly.

Get download trendGet a package's downloads day by day over a period, together with what the series says: the busiest and quietest days, the daily average, and whether the second half of the window ran ahead of the first. That last comparison is what turns a download count into 'rising', 'steady' or 'falling', which is the thing worth alerting on.

Compare package downloadsPut several packages' downloads side by side over the same period, ranked, each with its share of the group's total. Use it to settle 'which of these is actually used?' in one step. A name npm has never seen is reported separately rather than failing the comparison, so one typo does not lose the answer.

Get downloads by versionSee which versions of a package last week's downloads actually went to, each with its share of the total and the release channels pointing at it. This is the action that answers 'has anyone moved to version 5 yet?'. npm publishes this breakdown for the last 7 days only, so the period is fixed.

Get registry downloadsCount how many packages the whole npm registry served over a period. It is the denominator for any 'what share of npm is this?' question, and the way to tell whether a package's quiet week was its own or everyone's.