survey free text responses

* it was a mistake to let npm, inc. get as far as it did with what should have always been a part of the foundation (post Joyent).
* The CLI isn't the interesting part – the registry contains the value & needs to be safeguarded.
* I really strongly dislike Facebook and don't trust anyone that takes a paycheck or benefits at all from that brand.  NPM is know to not be well managed but I really don't like Facebook.
* "Dear God please don't ship Yarn by default. Not only are the maintainers unpleasant to interact with, the whole thing is just... bad.
* Most of the time fixing Yarn issues comes down to: ""Can you try npm instead?"". Making that a default experience would be a catastrophy."
* I am more concerned about the stability of the npm package management repo than necessarily npm vs yarn.
* I remember when node didn't come with a package manager, it was pretty bad
* the problem is not the package manager, it’s the registry. Currently the registry is not owned the foundation. no matter what the client is, we’re always bound to the npm registry and that is a problem we need to tackle 
* "I think people using npm is a bit like people using Internet Explorer. It came bundled and it was easier to continue with it for most, rather than explore other options. Since the main ethos around JavaScript these days is freedom of choice (be it module, package manager or framework), it would make sense to ask which package manager to use on install, but recommend a default choice. 
* The hard part is not getting drawn into the politics of why Node would endorse one package manager but not another."
* Not sure if this is the right place to bring it up but npm Inc existing at all is wild lol. Node install following something like go get would be cool
* maybe go the deno way of linking direct to package urls (with caching)
* Changing to X, says X is better than none which is not the responsibility of Node.js to comment on. npm is bundled with Node.js for historic reasons which is a fairly neural reason. Changing it to a minimal installer or a stub would only increase the barrier to entry. Which installer is used only matters for experts, and for them the barrier to install X is minimal. Additionally stubs opens up for arguments for also including Y and Z.
* A package manager version manager like NVM/FNM would be ideal
* The CLI isn't the primary issue: the registry is.  Clients and registries handling ESM correctly/consistency across the ecosystem will be critically important too.
* "I typically end up using yarn at work, but that's just due to their momentum in the development community. Everything I do in yarn I can do in npm; not to mention it's not entirely clear on the future of yarn, with that new package manager they're building.
* I think I prefer npm overall"
* As a company / community member, npm has proven itself undeserving of its quasi-monopoly. The stub idea also makes support for multiple package managers seem possible without too much user pain. Finally, Node is a very culturally-modular dev community, so modularizing this aspect of the core Node distribution also makes a lot of sense.
* More important for Node to own the registry now owned by npm and define the core around it, then let yarn etc build upon that rather than on npm
* Most people discussing this are more concerned with decoupling from the registry rather than the client. If you really want to do this, why not focus on the registry portion rather than the client? Properly resolving and installing dependencies is highly non-trivial, and Node.js has enough on its plate already, so doing this wrong (or even just DIFFERENTLY) would introduce a lot of ecosystem disruption. Yarn and NPM can already configure which registry they talk to, and it wouldn't be too hard to ship an NPM client pre-configured to talk to a different registry endpoint.
* would be nice to have a de-facto, inhouse solution for package management from Node.js
* We need a spec at Foundation level regarding package management
* I wish run scripts in the package.json were handled by an official standalone utility instead of being defined by npm
* npm works correctly for now and people already know how to get alternative options. So I don’t know how to feel about this whole thing.
* Thanks for asking the community, getting our input, etc, and carry on with the awesome work. 
* Please copy Deno
* I'd like Yarn and NPM to merge again—wishful thinking, but I'd like one standard that met everyone's needs—
* The constant debate over npm vs yarn vs some other solution is tiring. 
* Npm should rethink its platform dependant package management
* swapping to a more formally specified node managed standard could only be a good thing for the community
* Don't let the chaos spread!
* For yarn only the minimal shell that loads from the per project version could be used. https://classic.yarnpkg.com/en/docs/cli/policies/
* Node.js could put out a minimum set of rules/tests that a pkg manager should follow. It is ridiculous to have a neat tool like pnpm not working with popular packages because they depend on npm quirks.
* The ecosystem relying on a single commercial entity is the problem, not the client that connects to their service
* please take a moment to review all of NPMs ecosystem. its maddening, seeing packages like `is-number`, packages with 1-2 lines of code getting popular and their creators becoming famous
* "The black hole effect of the node_modules folder really needs an improvement. On a very basic front end project, you can end up installing hundreds of dependencies... Which are also not cached, thus creating several node_modules folders across your system, with thousands of files in them. The ecosystem should also really improve from creating certain packages that are simple enough to write yourself, instead of racking millions of downloads (say, is-number). Yarn v1 and pnpm are, in my opinion, doing the best local package management in this ecosystem. pnpm uses hard linking, yarn caches the tar balls locally iirc, which speeds up install times. It just gets really annoying to install a small to medium size front end project from scratch, which on a weaker PC (from a performance standpoint, not an internet speed one) will take forever to finish. 
* If node.js decides to add their own package manager, it should really do a good job at being fast, at actually working and not breaking like npm, but most importantly, to be consistent. "
* Careful with interactive prompts
* I am a Node contributor and daily user, but I think the Deno model may just be the right way to go about dependency management. In the mean time though, see my answers above.
* Node.js should ship and follow standard package manager using package.json, npm is quite good but we need to create newer owned pacakge manager to avoid current package managers (npm, yarn) stop the development.
* Don't make another for such a sensitive component, just add the effort to npm (or npm2, 3)
* I think the registry should be independent of the package manager or for-profit company making the package manager.
* The package manager ecosystem is fragmented enough (npm, yarn, pnpm). Let's rather consolidate them and contribute to a standard.
* yarn 2 worries me :/
* Not really, just a suggestion about the poll itself: IMO the first question should be a multichoice as in practice you can use npm and yarn depending on project/context.
* "Why does the opening question assume that people only use one package manager? 99% of respondents simply use whatever package manager the project maintainers have configured.
* Why is pnpm not mentioned in this survey?"
* Reliance on a single package manager/repository can be a bit of a pain, it'd be nice if we had someway builtin to install via multiple package managers/repositories/etc without annoying config e.g.: { "react": "npm:react", "lodash": "github:lodash" } combined with the above suggestion of `node --package`
* Cache artifacts in a global directory and use it to populate local node_module so if I have package A and B installed already I can still work on an airplane.
* Package managers controlling module resolution, like yarn pnp, should be standard
* npm having global and local packages was a genius idea. It’s probably the best package manager in that regard. Especially keeping everything separate for different projects. Some type of dependency tracking and de-duping might make sense to reduce the node_modules directory from being 1G in some repos. Otherwise all thumbs from me
* I think that pnp is the way, and should be incentivated
* Don’t break the ecosystem!
* Each package manager has trade-offs and should be noted as such to developers bootstrapping their environment with the runtime. 
* Npm needs help.
* I want the foundation to host registry
* f*** yarn
* standardise features and protocols so it is easier to roll your own package manger if you want to
* The problems with package management in the Node world mostly aren't with the package installers or registries.
* Prompt users if they download the official gui installer for desktop from node’s website and let all other system package managers handle npm/yarn/whatever as a distinct dependency
* The stubs concept is very similar to what volta.sh does, and works very well. 
* Registry being the responsibility of a for profit company is gonna bite us in the butt
* you need to control your own destiny: you need the registry, not just the client
* I like npm and I know I’m weird. I also don’t like Facebook 
* I personally have no big problem about package manager in Node. Yarn and NPM are almost equivalent (yarn's workspace is good though). I would use Node's native package when someone develop only if it has huge advantage (like compiling and packing a single executable from source, like Go).
* There’s a decent amount of movement created around modules. Having a conservative choice bundled (npm) and letting other userland solutions innovate (yarn berry) without the pressure of complete stability seems like a good bet right now.
* I think yarn/npm should be installed separately, maybe the default installer for windows/Mac include them, but global package management is already kind of a mess depending on how you installed node and might be better if npm/yarn weren't installed with node. 
* Node should build in a canonical package manager a. La. Go & Deno instead of bundling an external one. 
* npm should be retained to avoid breaking things, but another more respectable package manager should also be included and encouraged.
* id prefer package management like deno, golang...
* I find the way deno handles modules very compelling https://deno.land/
* Just want a default that’s simple, conservative, and technically consistent. If none exist, choice is good. I particularly like how FreeBSD and NetBSD handle packaging
* Node should just support es modules out of the box. On first run downloading and caching whole dependency graph locally. Use —reload flag to refetch modules. Package managers then can just turn into services like unpkg
* I don't think that the *client* is the main issue. npm as a client is fine. Node should probably keep it as the default option. But I am really scared what happens with the *public registry* if npm Inc. goes out of business - . I think finding a solution to *that* problem should be a major concern for the Node.js project. 
* What Deno is doing is very interesting. Maybe Node should do the same.
* Pnp would be awesome! 
* Most correct way would have been to not bundle the package manager. But now when that error was made already, I think you should keep bundling npm for historic reasons (so old tutorials/docs/books/etc keeps working). Adding more package managers just adds bloat and complexity.
* Please for gods sake anything but yarn they’re already insufferable 
* "Making npm the undisputed default let to its stagnation. Also, considering NPM Inc is a for-profit company unlike the Node Foundation, I think there's a need for choice at least if not a completely community-owned and distributed package manager. Both Yarn/Berry and pnpm are good candidates from this perspective.
* I'd say trying to ship a minimal package installer would complicate things even more by adding another package manager to the mix. "
* I don't like installation process output and time of npm, and I confused by Yarn update to version 2.
* help me to deal with tree dependance !! Plzzz 
* I don't believe npm will keep going forever. Their CLI went six months without contributions last year, and afaik most if not all contributions come from their company, significantly tying the development to their internal roadmaps (cf `funding`, which unblocked when NPM Inc decided to implement a sponsor mechanism).
* "Remove the package manager and let users figure it out.
* Alternatively ship with a small tool that downloads packages from GitHub using the git protocol."
* I like the idea of opening up the package manager system, I'm just mainly concerned that the introduced complexity of the choice is big compared to the benefit. What about trying to listen to the concerns and solutions brought by Yarn?
* "The idea Node.js has built-in package installer sounds good
* Providing stubs for npm and yarn may be needed during the transition to built-in package installer"
* Ship nvm please
* If it ain't broke, don't fix it.
* I believe Node.js should strongly push npm as the canonical client. Having a clear default setup is an improvement in UX, especially for newcomers, and the presence of yarn at this point is mostly creating confusion and complexity where none need exist.
* I’d love to see a timeline for removal of npm from the official distribution. If npm, Inc. wants to create a distribution that includes npm, let them do it. Same for yarn or any other package management client. The official distribution should, in the long term, support a OpenJS Foundation owned client that works with decentralized registries. 
* Is this a real issue?
* I personally prefer yarn, I used Vue and vue-cli has yarn as default. I think is less verbose too. But it's just my opinion after all. I think I could work with npm too, the main thing is, for me, to leave the possibility to change the package manager if necessary.
* get natalie involved
* I was on board with "make yarn the default" but no sure anymore with yarn 2.
* It's already pretty damn awesome. The best of any programming language ecosystem I've tried this far.
* I hope you folks don't get a lot of hate / pile-on in this. I think having competition in package managers has lead to improvements for all, and may continue to do so. I'm not sure how to keep that pressure for innovation while offering sensible, functional defaults though. I think shipping the 2 or 3 most popular ones with Node, and a mechanism for adding a stub for new ones when one is developed by the community?
* Should use URLs while requiring or importing a package as Demo does
* The most important thing is that the package manager is maintained by the same foundation that maintains Node.js itself.
* PnP compliancy by default
* Npm needs to go away. Node-gyp needs to be ejected as well meaning all native modules in the npm repo that do not update (eg CMake) are worthless going forward if they are not updated and kept current. Npm not supporting basic features (install this one package, locked at this version, in place, without a package.json file) hurts us. 50 different layers of modules all kind of supporting things like proxies (but not all the options) makes it a Byzantine maze to figure out what isn’t passing env cars or initializing curl or openssl the right ways. Npm the company will not last, best to start preparing now!
* Both npm and yarn have important bugs, it would be good to somehow ensure that fixing them is supported, financially or otherwise.
* I really like the idea proposed in GitHub discussion: a package manager should be a choice of each project that's documented via well-known machine-readable metadata, e.g. "engines.pm" in package.json. Node.js should provide a thin wrapper that will execute the project-configured package manager for common tasks like "npm install", plus a convenience tool for installing the package manager required by the project. 
* The registry is owned by npm so I would like to solve that issue, whatever prepares us for that future is the way to go.
* While NPM has it's issues, I think none are more severe then it being a for-profit company that doesn't align with Node's governance model. Whatever solution is chosen, it should align or perhaps be controlled by Node's governance. 
* The central registry is going to die with NPM, Inc. Best to get ahead of that with package management that doesn't need one.
* why does yarn even exist
* Focus on bare essentials, push us towards ES Modules :D
* Make npm so great that there isn't another choice
* pnpm is not considered in this survey, not fair. 
* Nuking the DX of having npm installed by default will invalidate a decade of tutorials and significantly increase the barrier to adoption.
* "Node.js is a runtime.
* It can simplify access to the ecosystem but it shouldn't become the package manager.
* Instead of Node.js stubs for package managers, a node --pm command to re-trigger the user's choice of package manager. Doesn't pollute the local binaries. ""which yarn"" bash scripts might otherwise think it exists, and break."
* Unless there's a lot of upside to changing things, it seems like we're just breaking things to break things. I'd prefer to just leave it as it is unless we can truly make things better/easier/more friendly to beginners.
* Why not go the other way around and make npm manage node versions that are installed. Make it an option in the package.json so that different projects can depend on different node versions, and have npm automatically pick the right one for the project (either if specified in the package.json, or the newest one).
* Yarn is better than npm but you can't break npm users but removing it from node bundles
* Oversized node_modules
* For beginners, I think it is better to ship npm by default. If they have any problems, they can find solutions easily. For others, it depends on projects, so we need to install both anyway.
* npm should adopt ideas from pnpm
* npm is the solution for this. We solved it and don't need to unsolve it.
* NPM as an entity has done a poor job of providing for the community's needs in the past 5 years.