The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
Hi y’all! This topic is the place where you can share and discuss shiny new ideas for what you’d like to see from tink as it develops. What’s the ideal package manager look like? What do we want from this? What do you see out there that you’d like to see in tink?
Share all your ideas!
While developing I often switch branches which have different dependencies in the package.json file. Would be nice if there was some kind of a watch mode which would auto-magically get my declared dependencies whenever I switch to a different branch.
Tink already does this!
It’d be nice if there was a dependency-graph aware “watch and restart on file change” built in. I use nodemon for this right now but I’m just watching all of my src folder
Reading through the tink README, I noticed the security audit feature, which to me is one of the more important features for a package manager going forward given the recent security issues involving npm packages. I don’t quite understand how tink works, but I imagine that package management should be an active process by which when a critical security issue arises, packages can be rolled back to a safe state automagically and block a build from executing if the security threat is present.
Should package management in general be handled by a dedicated local server that can make inquiries into the dependencies that it manages?
It seems that package management as a glorified file system may not be the best approach since things can go bad very quickly.
I should have probably tested it out before commenting
- Fix npm version pr project
- Make the lock file stable (no random hash/protocol/options changes)
- Speed, speed and speed (lives are lost in traffic - if summarized then while waiting on npm)
All in all consistency and speed.
I think this is viable, but maybe not something that fits in plans for tink:
(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)
How will workspace + building be supported?
workspaces will be natively supported, but they’re coming to npm first. Building will work just fine (in fact, webpack works right now with tink), so it’s not much of a concern there. Because of where tink inserts itself, any node-based builders will work out of the box without modification or plugins.
Is there any solution within tink that allows for “Singleton” Packages… e.g. packages where only ONE version should be available within the entire app?
This is already coming to regular npm! Hang tight for news
you mean? https://github.com/npm/rfcs/pull/23
and if it’s in npm it’s automatically in tink?
also especially in the FAQ it says
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.
so “singleton” is sort of global deduplicating right? so tink would not do it as it expects npm to do it? but PnP could do it? I’m a little lost who / where this feature best fits
Any fancy features that npm has, I expect to also have in tink when it gets finally released. That includes workspaces, singleton packages, overrides, aliases, etc etc. So I’m not really considering them “big tink features”, since they’re things npm will have anyway.
And no, “global deduplication” isn’t exactly singleton packages but they’re related and similar.
Awesome concept, I really love the idea of tink!
- Dependency management should be hassles during development, ideally you change a version number in package.json and you immediately are working with this version in your code, exactly like tink does.
- I’m always having trouble with the lock file not being stable, as already mentioned by @raix. After an npm install, there are typically a lot of changes in the lock file which is a huge hassle when working in a team.
- Unlike in development mode, you really want to have a way to freeze and bundle your application with all its dependencies in some container which you can deploy in the cloud. A production server having to fetch dependencies on the fly would not be a good idea. Now this is a grey area between a package manager and a bundler, so it may not be a task of the package manager directly, but it may be beneficial to be designed with this in mind (docs, guides, integration with webpack/heroku/aws/…).
My ideal package would download only once instead of keeping all dependencies in its own node_modules folder.
The only reason I use online editors such as CodeSandbox or Stackblitz is because it takes too long to download all packages even for small demo apps.
That’s already something tink does!
Future is here now