How to Build Real‑Time NPM Package Usage Dashboards for Frontend Teams

Preface

Hello frontend friends, today we officially launch the Kuaishou e‑commerce frontend team public account. With billions of daily visits and constantly evolving business challenges, our team has accumulated deep experience across many frontend domains and wants to share our problems, solutions, and thoughts with the community.

Background

In a typical frontend team, dozens to hundreds of npm packages are used in production. Currently we have over 200 npm packages, and the number keeps growing. There is no effective way to automatically monitor the online usage of these packages; statistics are done manually because there is no dedicated online monitoring solution.

Goal

Build a dashboard that provides real‑time visibility of npm package usage in production.

Solution Overview

Solution 1: Integrate a Log‑Collection SDK Inside Each npm Package

Implementation

Developers manually invoke a log‑collection SDK inside their npm package to report information, then view the data on the SDK’s monitoring panel.

Drawbacks

Data reporting depends on the log‑collection SDK; upgrades to the SDK may require synchronized updates to each npm package.

Each package must be reported manually, creating a large workload and relying on developers to provide accurate data.

Only package information is reported, without linking to specific business projects, making it hard to view usage by project.

Solution 2: Point‑Collect SDK + Point‑Report SDK

We split the requirement into two actions: point collection and point reporting. The existing log‑collection SDK acts as the reporter, while a lightweight point‑collection SDK is added to every npm package.

We provide two tiny packages: @log-collect for collection and @log-report for reporting.

Implementation

@log-collect : Injected into npm packages, it attaches package name, version, custom extensions, and custom events to window.__NPM_LOG__.

@log-report : Sends the collected data at appropriate moments (e.g., route changes, document visibility) and clears window.__NPM_LOG__ after reporting.

Usage

From the npm‑package developer’s perspective:

// In the npm package, import @log-collect
import npmCollect from '@log-collect';
// Create a logger instance with package name and version (optional custom params)
new npmCollect({name: '__NAME__', version: '__VERSION__'});

// Example with Rollup: replace package name and version at build time
// rollup.config.js
import replace from "rollup-plugin-replace";
import pkg from "./package.json";
export default {
  // ...
  plugins: [
    replace({
      __VERSION__: process.env.VERSION || pkg.version,
      __NAME__: process.env.NAME || pkg.name
    })
  ]
  // ...
};

From the business code perspective:

// Install and use @log-report in the application
import npmReport from '@log-report';

new npmReport({
  sampling: 0.01, // sampling rate
  filter: () => true, // custom filter function
});

Drawbacks

Both the npm package and business code need to be modified, leading to higher integration cost.

Potentially large amounts of duplicate data are reported, consuming resources.

Solution 3: Webpack Plugin

We provide a webpack plugin @log-webpack-plugin that collects npm package information during the build process and uploads the results to a database. A custom dashboard can then query this data.

Implementation

The plugin hooks into webpack’s compilation process, extracts each package’s name, version, size, import path, and third‑party dependencies, and sends the data to a backend service.

Usage

Installation npm install --save-dev @log-webpack-plugin Configuration

const NpmLoggerPlugin = require('@log-webpack-plugin');
// webpack config
module.exports = {
  // ...
  plugins: [
    new NpmLoggerPlugin({
      includes: [], // string | array
      excludes: []  // string | array
    })
  ]
  // ...
};

Dashboard

The uploaded data can be visualized in a custom dashboard.

Drawbacks

The solution requires significant development effort: building the webpack plugin, setting up the database, implementing APIs, and creating the dashboard.

Conclusion

Comparing the three approaches, the webpack‑plugin solution is the most developer‑friendly and offers the greatest flexibility for data queries. It requires no changes to individual npm packages, and business teams can integrate the plugin into their project templates to reduce onboarding costs.