npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

tink: State of the Unwinder [2018/10/25]

Hello frens~

I’m hoping to have folks from the community jump in with tink-related things, especially building up more ecosystem things around it and starting to get early impressions, so here’s a quick update of where development is:

overriding node functionality

This is mostly in place! On top of the earlier fs.readFile* and such support, you can also now do directory-related operations, such as fs.stat on directories inside the package-map directory, fs.readdir, etc etc.

Aside from filesystem operations, tink now uses spawn-wrap so any child node processes spawned by a parent tink process should be automatically and transparently tink-ified, even if you started them with node!

Finally, tink now downloads dependencies inline if your cache ends up getting corrupted or such. In the future, this might become a lazy-loading feature that lazily installs packages. This is probably best left for esm-based packages, since we get a nice blob of dependencies to request, and require would be very slow and blocking and still benefits from the current pre-loading.

TypeScript and JSX

That’s right, friends! tink now supports both typescript and jsx (and .tsx) out of the box! No configuration necessary. Just require a .ts, .jsx, or .tsx file and it should just work!

It’s pretty rudimentary, and there’s a TODO to make this more configurable and featureful. We might try working with Certain Third Parties™ on getting this right.

auth and config

I’ve gone ahead and written a config loader that supports .npmrc and all current npm config variables. Right now, the only way to pass them in is through npm_config_cache=..., npm_config_loglevel=... and such (or writing them into .npmrc), but it’s not a big step to start accepting CLI options from there.

This means that auth is supported, so you should be able to use tink with custom registries and private packages that require auth information to be sent! Just npm login and you should be good to go.


At this point tink is able to require any packages I’ve thrown at it. Especially thanks to all the node override work that’s been going on.

Additionally, if you have a package that you want to edit directly, or that you can’t get to work with tink, you can simply extract it to node_modules/ and it will take priority over the package-mapped version! A better UX around this is TBD.

Next Steps Roadmap

So, what’s next? Here’s the current TODO list. Is there anything here you wanna pick up? Go ahead! Ping me if you have any questions.

Is that config loader available as a separate package? It’s the biggest pain point in using libnpm right now, in my experience.

The plan is to extract it to a new config loader, yeah. I’ve been laying a lot of the groundwork for that with figgy-pudding, but there’s a couple of bells and whistles I’d rather have before it gets extracted, so it’s actually properly compatible.

Understandable, looking forward to it. I’d be delighted to help beta test the config loader, if it is helpful.