3 ms·
I can't say I appreciate adding package.json support, but I also don't see it as necessarily a bad thing. In my opinion, it would be a bad thing if this encour
by ravenstine 4y ago
I can't say I appreciate adding package.json support, but I also don't see it as necessarily a bad thing.
In my opinion, it would be a bad thing if this encouraged everyone to start using Deno as a stand-in for Node and make more Node patterns typical in Deno development. If package.json is there merely for backwards compatibility then that's one thing. On the other hand, if things drift towards doing everything the Node way again... well, I'm sure there's someone this very moment writing a "better" package manager for Deno that "solves everything for real this time." And I don't look forward to the flurry of package managers for Deno. Who's ready to decide whether "nary" is better than "dpm" or "pdpm"?
- nikisweeting 4y agoExactly, I hope Deno gaining mass adoption will move the industry away from NPM dependency hell. This is just a stepping stone to get more projects on board with that mission by giving them a practical migration path from the old system.
- wokwokwok 4y ago> it would be a bad thing if this encouraged everyone to start using Deno as a stand-in for Node and make more Node patterns typical in Deno development It’s hard to see how adding package.json and the node compatibility layer is not going to make this like pypy. Ie. Highly compatible, technically distinct, practically irrelevant and not quite perfect dropin replacement for just using node to run your “designed for node” code.
- nikisweeting 4y agoFor one pypy doesn't offer an entirely new security model or standard library that displaces hundreds if not thousands of old 3rd party packages.