tink: State of the Unwinder [2018/11/05]

help-wanted
tink

(Kat Marchán) #1

Holy cow! It’s been a week!

I’m happy to say tink dev has ramped up significantly since I last wrote about this. I’ll try and summarize everything here and then talk about next steps!

Call for Collaborators

Probably the most noteworthy bit here is that I asked for help with development, and BOY HOWDY did y’all deliver. Literally brings a tear to my eye. Every time I posted something that I could use help with, it would get snatched up within minutes. There’s also still a couple of ancillary subcommands available, if you’re interested in jumping in! Get 'em while they’re hot!

I’ll keep posting new things as I come up with them and I think new folks can jump in and help, so keep an eye out.

So far, y’all have volunteered to add:

Thanks everyone! I’ll have even more for you very soon!

Proper tink releases

As you may or may not have noticed, I’ve not only been pushing to the git repository, but tink is actually available on the npm registry itself! That means that trying out tink in its current development state is as easy as $ npx tink --help! I don’t know if I’d say it’s quite -usable- yet, but enough bits of it work that you can totally try it out right now and start getting a feel for it.

Since there’s releases, that also means there’s now a tink CHANGELOG.md that describes all the released changes! I’ll be posting select bits here on a weekly basis, but if you want to keep up and make sure you know all the details, go check that link out.

Most fs operations supported

You heard that right. You can now do most fs.* operations directly and, if you end up pathing into a node_modules directory, it’ll potentially switch to the virtual mode, with files getting loaded directly off the cache. This is the fundamental feature of tink and I’m excited it’s working! There’s a few more fs operations missing, and this of course needs tests (something I’ll be reaching out to the community for help with soon), but hey, it does the thing!

Webpack support

Not just webpack support, but it’s the one I tested. Because the above works, it means pretty much any tooling that goes through Node’s fs operations will work just as usual – this includes Webpack, and probably every other bundler! I tested this with create-react-app's build scripts, too, and can confirm that I could build a CRA app with tink, and no node_modules packages!

Goodbye .package-map.json!

This is the most recent change, and exciting in its own right. I’ve stopped having tink dispatch off .package-map.json and removed all the relevant patches from the node resolver. That means that the only patches to Node’s module loader are just to add TypeScript and JSX support, and to get certain fs overrides to actually apply. The rest of the behavior is basically identical to before! This will make compatibility even better, and it makes fallbacks super easy.

That’s right: You can now put anything in node_modules and individual files can be overridden as needed. You can patch individual files inside that directory, and they’ll only override that one file. No need to copy entire packages out of the cache!

Oh, and tink supports graceful-fs now, too.

Subcommand Sketches

One last thing: I’ve started sketching out the various tink subcommands. So you can take a gander right now and get a feel for how using tink will actually feel! Let me know what you think.

Next Steps

So what’s next? Something like this:

  • Implement more of the documented subcommands.
  • Finish the pkgmap -> pkglock refactor.
  • Get lazy dep loading fully working.
  • Hack together a proxy server for lazy loading of individual files off a future hypothetical registry API. That’s right, you’ll never download a README.md again unless the user actually tries to read it. :sunglasses:
  • Start writing tests for current functionality.

Conclusion

Lots of exciting stuff coming this week! Please keep an eye out for things to contribute to if you want to help – I mean, who wouldn’t want to be at the vanguard of our little revolution in package management? There’s nothing quite like tink, and there won’t be, for a while. So let’s kick ass!


(Steven) #2

It looks like travis is not enabled: https://travis-ci.org/npm/tink


(Borek Bernard) #3

Hi @zkat, thanks for all the info!

I didn’t follow tink closely so far but why is it a separate package manager and not e.g. a new mode of npm, sort of like Yarn’s PnP? Is it because it’s also patching / replacing Node? When running an app, should I use tink server.js instead of node server.js? Or maybe I’ll be able to do tink server.ts directly without ts-node?

Sorry for newbie questions, I’m still trying to understand what exactly tink is and why is it a separate project. Thanks!


(Kat Marchán) #4

It’s easier to prototype things as standalone packages before integrating. This is especially true when developing new UX workflows.

The plan is to develop tink on its own and eventually it’ll become npm itself.

I know it may seem like a lot of reinventing the wheel, but the fact is that they already share 99% of their code. The npm codebase is heavily modularized, so they pretty much do most things the exact same way and you can expect the same workflows, but better. I can only assume Yarn cooks everything into a single codebase because it’s a monolith and, to be frank, PnP is not remotely anything like tink and comparing them would be unfair to Yarn.

For example, you’ll never have to do npm install again. And yes, tink start will automatically load server.ts without having to install ts-node at all.


(Kat Marchán) #5

p.s. There’s a FAQ for tink now If you have any other questions.


(Borek Bernard) #6

FAQ is awesome to have, thank you.

Maybe it’s hard for me to accept what tink does / is as it just sounds too good to be true :slight_smile:


(Kat Marchán) #7

It’s very good and it’s very true