Gathering detailed insights and metrics for analyze-module-size
Gathering detailed insights and metrics for analyze-module-size
Gathering detailed insights and metrics for analyze-module-size
Gathering detailed insights and metrics for analyze-module-size
npm install analyze-module-size
Module System
Unable to determine the module system for this package.
Min. Node Version
Typescript Support
Node Version
NPM Version
12 Stars
44 Commits
2 Forks
2 Watching
3 Branches
2 Contributors
Updated on 27 Jan 2023
JavaScript (93.14%)
HTML (6.86%)
Cumulative downloads
Total Downloads
Last day
7.1%
121
Compared to previous day
Last week
21.9%
429
Compared to previous week
Last month
14.3%
1,809
Compared to previous month
Last year
37.5%
28,035
Compared to previous year
Analyze the size of your module dependencies
analyze-module-size
shows you, why your package is so large. The reason for the size
of your package often lies in the dependencies you are using. For example request@2.81.0`
is 7080kb large (including its 53 dependencies) and it comes with a lot of libraries that you may not even need. If you are aware of that, you may choose to use a different library
(e.g. popsicle).
The module cost-of-modules does the same, but it only shows one level of the dependency tree. It was an inspiration, but I took no code from it.
Finally, this program still has a lot of opportunities for enhancement. If you have wishes, ideas or questions, please open an issue.
npm install -g analyze-module-size
Run analyze-module-size
in your project directory. The output will be something like this:
(Note that the displayed sizes are accumulated from the each module an its dependencies):
size: 68k... with-dependencies: 1204k
├─┬ globby@6.1.0, 488k, 17 deps
│ ├─┬ glob@7.1.2, 344k, 10 deps
│ │ ├─┬ minimatch@3.0.4, 136k, 3 deps
│ │ │ └─┬ brace-expansion@1.1.11, 88k, 2 deps
│ │ │ ├── concat-map@0.0.1, 40k, 0 deps
│ │ │ └── balanced-match@1.0.0, 24k, 0 deps
│ │ ├─┬ inflight@1.0.6, 60k, 2 deps
│ │ │ ├─┬ once@1.4.0, 40k, 1 deps
│ │ │ │ └── wrappy@1.0.2, 20k, 0 deps
│ │ │ └── wrappy@1.0.2, 20k, 0 deps
│ │ ├─┬ once@1.4.0, 40k, 1 deps
│ │ │ └── wrappy@1.0.2, 20k, 0 deps
│ │ ├── fs.realpath@1.0.0, 32k, 0 deps
│ │ ├── inherits@2.0.3, 24k, 0 deps
│ │ └── path-is-absolute@1.0.1, 20k, 0 deps
│ ├─┬ pinkie-promise@2.0.1, 44k, 1 deps
│ │ └── pinkie@2.0.4, 24k, 0 deps
│ ├─┬ array-union@1.0.2, 40k, 1 deps
│ │ └── array-uniq@1.0.3, 20k, 0 deps
│ ├── object-assign@4.1.1, 20k, 0 deps
│ └── pify@2.3.0, 20k, 0 deps
├─┬ glob@7.1.2, 344k, 10 deps
│ ├─┬ minimatch@3.0.4, 136k, 3 deps
│ │ └─┬ brace-expansion@1.1.11, 88k, 2 deps
│ │ ├── concat-map@0.0.1, 40k, 0 deps
│ │ └── balanced-match@1.0.0, 24k, 0 deps
│ ├─┬ inflight@1.0.6, 60k, 2 deps
│ │ ├─┬ once@1.4.0, 40k, 1 deps
│ │ │ └── wrappy@1.0.2, 20k, 0 deps
│ │ └── wrappy@1.0.2, 20k, 0 deps
│ ├─┬ once@1.4.0, 40k, 1 deps
│ │ └── wrappy@1.0.2, 20k, 0 deps
│ ├── fs.realpath@1.0.0, 32k, 0 deps
│ ├── inherits@2.0.3, 24k, 0 deps
│ └── path-is-absolute@1.0.1, 20k, 0 deps
├─┬ chalk@1.1.3, 144k, 6 deps
│ ├─┬ has-ansi@2.0.0, 40k, 1 deps
│ │ └── ansi-regex@2.1.1, 20k, 0 deps
│ ├─┬ strip-ansi@3.0.1, 40k, 1 deps
│ │ └── ansi-regex@2.1.1, 20k, 0 deps
│ ├── ansi-styles@2.2.1, 20k, 0 deps
│ ├── escape-string-regexp@1.0.5, 20k, 0 deps
│ └── supports-color@2.0.0, 20k, 0 deps
├─┬ debug@2.6.9, 132k, 1 deps
│ └── ms@2.0.0, 20k, 0 deps
├── lodash.sortby@4.7.0, 88k, 0 deps
├── commander@2.15.1, 76k, 0 deps
├── archy@1.0.0, 52k, 0 deps
├── graceful-fs@4.1.11, 48k, 0 deps
├─┬ deep-aplus@1.0.4, 44k, 1 deps
│ └── lodash.isplainobject@4.0.6, 20k, 0 deps
├── progress@2.0.0, 44k, 0 deps
├── p-map@1.2.0, 20k, 0 deps
└── pify@2.3.0, 20k, 0 deps
Usage: analyze-module-size [options]
Analyzes the size of the package in the current directories, including the size of (production) dependencies
Options:
-V, --version output the version number
-d, --depth <levels> Show only dependencies up to a given depth of recursion
-h, --help output usage information
`` collects all modules from the node_modules
directory, the node_modules
directory of
each of those modules and the node_modules
directory in that modules, and so on.
When all packages have been collected, it reads the package.json of each module and uses the _location
-property
and the _requiredBy
-property to recreate the complete dependency tree.
_location
contains the location of the module in the directory tree. A module in node_modules/packageA/node_modules/packageB
has the location /packageA/packageB
_requiredBy
contains a list of module that are dependent on the current module. For each such module, it contains
the value of the _location
-property.Once the packages is connected, the stats for each package are computed:
blksize
-property
of the fs.Stats-object is used as block size. If this value is missing (e.g. on Windows), a size of 4096 is
used.In some cases, the dependencies in the node_modules
-directory are tampered with. For example, lerna
combines dependencies of multiple packages in the node_modules
-directory of the root-project and removes
obsolete dependencies from the tree. This can lead to cycles in the dependency tree which are displayed in
the output like this:
1size: 42k... with-dependencies: 42k 2└─┬ dep1@1.0.0, 42k, 3 deps 3 └─┬ dep1a@1.0.0, 42k, 3 deps 4 └─┬ dep2@1.0.0, 42k, 3 deps 5 └── dep1@1.0.0 (cycle detected) 6
Furthermore, this and the use of optional dependencies can lead to a situation where a package is _requiredBy
an existing dependency (i.e. a dependent package) but does not exist anymore in the tree. For those delete packages,
a dummy package is displayed in a separate tree.
1size: 42k... with-dependencies: 42k 2└── dep1@1.0.0, 42k, 0 deps 3 4missing packages, that are referenced as dependent of an existing dependency 5└─┬ /dep3, 42k, 2 deps 6 └─┬ dep2@1.0.0, 42k, 1 deps 7 └── dep1@1.0.0, 42k, 0 deps 8
In this example, a module dep2@1.0.0
was found. The _requireBy
-property shows that dep2
is part of the tree, because it is a dependency of a module that should be in node_modules/dep3
,
which could not be found.
analyze-module-size
is published under the MIT-license.
See LICENSE.md for details.
For release notes, see CHANGELOG.md
See CONTRIBUTING.md.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
Found 1/22 approved changesets -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Reason
SAST tool is not run on all commits -- score normalized to 0
Details
Score
Last Scanned on 2024-11-18
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More