pnpm / tabtab

tab completion helpers, for node cli programs & others. Inspired by npm completion

简体中文 | 日本語 | 한국어 | Italiano | Português Brasileiro

Fast, disk space efficient package manager:

• Fast. Up to 2x faster than the alternatives (see benchmark).
• Efficient. Files inside node_modules are linked from a single content-addressable storage.
• Great for monorepos.
• Strict. A package can access only dependencies that are specified in its package.json.
• Deterministic. Has a lockfile called pnpm-lock.yaml.
• Works as a Node.js version manager. See pnpm env use.
• Works everywhere. Supports Windows, Linux, and macOS.
• Battle-tested. Used in production by teams of all sizes since 2016.
• See the full feature comparison with npm and Yarn.

To quote the Rush team:

Microsoft uses pnpm in Rush repos with hundreds of projects and hundreds of PRs per day, and we’ve found it to be very fast and reliable.

Platinum Sponsors

Gold Sponsors

Silver Sponsors

Support this project by becoming a sponsor.

Background

pnpm uses a content-addressable filesystem to store all files from all module directories on a disk. When using npm, if you have 100 projects using lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be stored in a content-addressable storage, so:

1. If you depend on different versions of lodash, only the files that differ are added to the store. If lodash has 100 files, and a new version has a change only in one of those files, pnpm update will only add 1 new file to the storage.
2. All the files are saved in a single place on the disk. When packages are installed, their files are linked from that single place consuming no additional disk space. Linking is performed using either hard-links or reflinks (copy-on-write).

As a result, you save gigabytes of space on your disk and you have a lot faster installations! If you'd like more details about the unique node_modules structure that pnpm creates and why it works fine with the Node.js ecosystem, read this small article: Flat node_modules is not the only way.

💖 Like this project? Let people know with a tweet

Getting Started

• Installation
• Usage
• Frequently Asked Questions
• Chat
• Twitter

Benchmark

pnpm is up to 2x faster than npm and Yarn classic. See all benchmarks here.

Benchmarks on an app with lots of dependencies:

Usage Trend

Usage Trend of pnpm

Backers

Thank you to all our backers! Become a backer

Contributors

This project exists thanks to all the people who contribute. Contribute.

License

MIT

tabtab's Issues

Better handling of suggestions with colons

Problem

When you return a suggestion like foo:bar, tabtab interprets foo as the completion and bar as its description. This already seems like a bad idea, but it is what it is.

To have more flexibility, if you have a foo:bar suggestion with a description, you can return something like:

{
  name: "foo:bar",
  description: "this is a very useful command"
}

So far so good. The problem is when you have a foo:bar command and you don't care about descriptions. I would have assumed that just using:

{
  name: "foo:bar"
}

would've been enough. But this has the same result as just returning foo:bar. The only way to work around this now is to return:

{
  name: "foo:bar",
  description: " "
}

Notice that description has a space: using an empty string doesn't work.

Suggested solution

I think that any time an object is returned instead of a plain string, the name should be interpreted as a completion. Besides, the description field should be optional, and it shouldn't change how the name entry is interpreted.

Invalid `.bashrc` lines on Windows -- slashes are not escaped

Full report in the main repo: pnpm/pnpm#5420

I know that Windows isn't supported, but at least for Bash the only thing preventing it from working is that the installer writes paths with single \ characters into the bash files, which then escape their neighbors instead of being used as path seps. Manually replacing those with posix-style / is sufficient to get it working on Windows + Bash.

I'm mostly cross-posting this here for others to reference if they're trying to get this working on Windows.

Option to autocomplete files

Problem

tabtab only lets you generate an array of suggestions, which is then passed to the shell's completion engine. This is fine for several cases, but it's pretty bad for filesystem autocompletion, for two reasons.

First, you have to manually implement this. It's not that hard, but it feels like a waste of effort.

Second, and more important, the ad-hoc filesystem autocompletion that you can do is way worse than the native filesystem completion of the shell. The native autocompletion has a better handling of directories, hidden files, showing different colors for different types of files, etc. There's no way this can be done merely with an array of string suggestions.

Proposed solution

Add a mechanism that tells the autocompletion script "just complete with the filesystem". This needs two things:

1. Updating the completion scripts to do this. This, I think, isn't that hard (I think I can do it for the bash and zsh scripts).
2. Having some way of communicating to the script that you want to trigger the filesystem completion. The easy way would be to return some token, like __tabtab_fs_completion__, and to check that. The downside here is that then __tabtab_fs_completion__ cannot be a valid suggestion but... that seems like an acceptable trade-off to me.

If you think this is something you would like to include in this project, I can try to send a PR, but I'd like to know that there's interest on this feature before working on it.

List available scripts when `run` is omitted

Hello,

This is a feature request.

Since the run keyword is optional and commands can be triggered using pnpm myscript, it would be nice to list available commands when using pnpm <tab><tab>.