npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

lede-cli

v3.0.1

Published

A CLI for lede projects

Readme

#Lede-CLI Lede-CLI is a command line interface for managing Lede projects.

CLI commands

The following is a list of commands. The sub-bullets under the command are the options the command takes. A * next to the command means that the command supports at least one additional subcommand.

new

The new command allows you to quickly scaffold out new pieces for a lede project.

  • Syntax: lede new <type> <name> [options]
  • Aliases: none
  • Subcommands:
    • Type: project | bit | block | page
    • Name: any string
  • Options:
    • --path | -p: A string specifying a path where the command should be run. Defaults to process.cwd().
    • --inline | -i: A boolean that specifies the new command should run in the current directory and not create a subdirectory. Defaults to false. Only valid with type project
    • --template | -t: A string specifying a template that should be used. Defaults to default.
  • Examples:
    • lede new project foo --inline --template photo -> Create a new project named foo in the current directory using the photo template
    • lede new bit bar -> Create a new bit named bar in the current directory
    • lede new block baz -t slider -p ~/foo/bar -> Create a new block named baz at path ~/foo/bar with the slider template
dev

The dev command builds a project and serves it. While dev is running, it watches all of the project's components and automatically rebuilds and refreshes the page if any changes are detected.

  • Syntax: lede dev [options]
  • Aliases: none
  • Subcommands: none
  • Options:
    • --port | -x: An int specifying a port for the dev server. Defaults to port 8000.
    • --path | -p: A string specifying a path where the command should be run. Defaults to process.cwd().
  • Examples:
    • lede dev -> Runs the dev server in the current directory listening to port 8000.
    • lede dev --path ~/foobar -x 1337 -> Runs the project at path ~/foobar with the dev server on port 1337.
install

The install command is used to install lede_modules from a registry.

  • Syntax: lede install [<module>...] [options]
  • Aliases: none
  • Subcommands:
    • [<module>...] optionally specify one or more modules to install. If this subcommand is not specified, lede will look for a ledeModules property on the package.json and install the modules listed there. Modules are typically specified in the format <moduleName>.v<versionNumber> (ex: photo.v1 would be version one of the photo module).
  • Options:
    • --path | -p: A string specifying a path where the command should be run. Defaults to process.cwd().
    • --fetcher | -f: A string specifying a fetcher to use to get the modules from the registry. Defaults to default.
  • Examples:
    • lede install --path ~/foo -> installs lede_modules at path ~/foo that are specified in the ledeModules property on ~/foo/package.json.
    • lede install foo.v14 -f gdoc -> installs the version 14 of the foo module into the current project using the gdoc fetcher.
save

The save command saves a project to the registry as a lede module. To save a module to the registry, you must specify a unique, integer version number in the projectSettings.js file.

  • Syntax: lede save [options]
  • Aliases: none
  • Subcommands: none
  • Options:
    • --path | -p: A string specifying a path where the command should be run. Defaults to process.cwd().
    • --fetcher | -f: A string specifying a fetcher to use to send the module to the registry. Defaults to default.
  • Examples:
    • lede save -> saves the current project to the registry using the name and version number from the projectSettings.js file.
    • lede save --path ~/foo/bar -f other -> saves the project at ~/foo/bar to the other registry using the name and version number from the projectSettings.js file.
listmodules

The listmodules command lists all available modules and their versions available in the registry.

  • Syntax: lede listmodules [options]
  • Aliases: lm
  • Subcommands: none
  • Options:
    • --fetcher | -f: A string specifying a fetcher to use to search the registry for modules. Defaults to default.
  • Examples:
    • lede lm -> lists all modules and their versions on the registry
    • lede listmodules -f borp -> lists all modules and their versions on the registry using the borp fetcher.
configure

The configure command allows the user to pull in custom configurations from a github repo. Useful if you want access to a custom set of templates or fetchers. Installs configurations into ~/ledeConfig (or %USERPROFILE%\ledeConfig on windows).

  • Syntax: lede configure <repo> [options]
  • Aliases: config
  • Subcommands:
    • <repo> is a required subcommand that specifies a github repo to pull the configuration from. Uses the syntax <owner>/<repoName>.
  • Options:
    • --token | -t: A string specifying a github access token to use for the request to github. Defaults to GH_TOKEN environment variable.
    • --npm: A string specifying an npm script to be run after pulling the repo down and installing it's dependencies. Useful if you need to transpile your configurations before they can be used. If not specified, no npm script is run.
  • Examples:
    • lede config foo/lede-configs -> installs configurations from the foo github user's lede-configs repo using the access token specified by GH_TOKEN environment variable.
image

The image command allows the user to send images off to be resized/hosted. The actual implementation of the image handling is defined by a fetcher. The default fetcher uses s3 and lambda for storing/resizing images.

  • Syntax: lede image [options]
  • Aliases: images
  • Subcommands: none
  • Options:
    • --fetcher | -f: A string specifying a fetcher to use to store the images. Defaults to default.
    • --path | -p: A string specifying a path where the command should be run. Defaults to process.cwd().
    • --clobber | -c: A boolean specifying if lede should overwrite existing files with the same name.
    • --bucket | -b: A bucket name lede should save the images too. Defaults to "ledejs".
build

The build command builds the project for production and puts the output in the outDir specified by the CLI config. By default, this is the directory dist in the project root. From here, the project can be pushed up to a file server for hosting.