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]
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
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
.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_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.
- TODO More convenient UX around extracting individual packages into
node_modulesto override pkgmapped once. Make sure this works as expected.
- TODO Enable non-
.mjs-based ESM loading out of the box.
- TODO Support
run-scripts for dependencies and the toplevel package.
- TODO Support
node-gypbuilds and caching of build results.
- TODO Support
manpage linking. This will allow transparently having local binaries working, like
- TODO Write a
tink-loaderto get webpack to support resolving modules through
.package-map.jsonpaths. Getting some help with this would be ace.
- TODO Better support for TypeScript and JSX: allow choosing JSX and TS versions, error levels and reporting, and passing specific options to each compiler (whether to typecheck TS or just load it, what renderer to compile down to for JSX, instead of just
- TODO Work on
tink's CLI options or subcommands and find a good UX around this.
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.