I keep getting the same questions about tink, and that probably means it’s a good time to start a FAQ. I’m going so glad there’s so much interest as curiosity and I hope this helps answer all your questions.

Have a question that isn’t here? Reply and I’ll probably add it!

What is tink?

tink (GitHub repo) is a new, experimental package manager developed by the same team that maintains the npm CLI. It is meant to be a greenfield experiment that allows us to try out new strategies for what a modern package manager might look like without risking breaking workflows for our 10 million users or forcing them to learn something new.

What’s the current status of tink development?

There’s a series of update posts you can keep an eye on called tink: State of the Unwinder. I’ll continue posting these, but for the moment, they’ll be weekly. Expect it to slow down as tink settles a bit. They talk about what happened since the last post, what’s cool to check out, what’s next, and who’s helped.

What’s special about tink?

The main difference between the npm CLI and tink is that tink does not have an install command and, with that, it doesn’t install packages into node_modules most of the time. Instead, it lazily installs dependencies into a secure central cache shared across projects in your system and loads everything by overriding fs operations in node.

You “install” things by adding them to package.json and then running your JavaScript or Typescript files using tink as your node binary.

You may also be familiar with Lerna, a tool that allows maintainers to publish many small packages from a monorepo so their users can require subsets. This style of publishing is used by widely-used tools like Babel and lodash. With tink, this use-case would no longer be necessary, because tink wouldn’t even bother download files you don’t use. Want to use lodash.map but not the rest of lodash? Add the entire lodash package to your deps and when your import 'lodash/map' , tink will only download files for that function and nothing else!

Oh right, and it does a lot of neat little things like load Typescript and jsx and ESM files out of the box without having to install or configure anything. And it has refreshed versions of all the usual npm commands like search. And it lets you override individual files in dependencies if you need to. And lots of other stuff!

What languages does tink support?

tink isn’t just a plain Node.js wrapper. It includes support for several other languages/syntaxes out of the box:

ES Modules ( import / export )

/ ) Typescript

JSX

(tbd) Your favorite thing.

What will happen to the npm CLI? Do I have to learn a new thing?

Once tink matures beyond being an experiment and it’s been in general use for long enough to prove its worth, we intend to sunset the current npm CLI and rename tink to npm. It will be a big change, but most things will work the same, even if the installer looks very different.

Wait, does that mean tink is going to be doing package management in the background in production?!

Nope! In production settings, when NODE_ENV=production or --production are used, all package management at runtime is disabled, and you’ll have to do tink prepare to make sure everything that needs fetching is fetched. Things will work (and fail) normally from that point on.

What is the difference between tink and Yarn PnP?

On the surface, they seem like the same thing: both are strategies that involve removing node_modules extraction operations, and thus are both ways to hugely speed up package management work.

But that’s where the similarities end.

Yarn PnP works off a runnable pnp.js file that is used as a new entry point for your application and needs to be regenerated whenever your dependencies change. It also works by overriding Node’s require and redirecting dependency loading towards their own resolver. This means you still need to manually ask for dependency installations, generate the pnp file, and even use special loaders for bundlers like webpack, testing frameworks like Jest, and compilers like Typescript. It also makes dependencies with installer scripts harder to work with and discourages them.

On the other hand, PnP’s approach allows it to do some interesting things like globally deduplicating packages by name even if they’re in different parts of the tree, and reduce initial load times by a significant % if your app takes a long time to start.

tink’s approach is fundamentally different. It works by removing most package management operations and making everything as automated as possible, overriding FS operations instead of the module loader. This means you don’t need anything extra, and it means most things will work out of the box without any patching, since tink is strongly focused on compatibility and simplifying workflows.

Even though it’s young, it can already be used with create-react-app and even use its complier, without having to do anything special at all. tink does not require loaders or special configuration for compatibility at all. And if you need access to a dependency outside of node or if you have run-scripts that modify dependencies or compile new files, that works out of the box and tink will make the files available as needed (or you can use tink unwind to put everything into node_modules as usual.

This is super cool and exciting! Can I help at all?

YES! We’d love some help with this, and there’s plenty to do for folks at any level. Check out tink: Helping out with development for more details!

Will tink make me cool and popular?

Yes, it’s one of the main features. You’ll also become a thought leader. It also punches Nazis.

Did you know tinking is a technical term in fiber arts? Why did you call it tink?

What? Me? Never Maybe it has to do with “tinkering”?

Some folks have asked if this has anything to do with Tinkerbell, but I don’t wanna get sued by Disney.