Is Conventional Package Management via Package.json still the right thing?
Closed this issue · 12 comments
Discussion
Is usage of a JSON file as application entrypoint as also Installer Meta data Provider the right thing?
Overall my observation is that even the NodeJS Stack does not use the Package.json because the format is simply not optimal
most people are switching to yarn lock for good reason and NodeJS internal already produces package-json.lock
that shows that the source format is useless anyway we could directly have a lazy Loading ESM Entrypoint. This pattern would also be more easy port able to the web.
In fact the usage and existing of a .json entrypoint broke a lot of parts of the web interop so people started to move bundlers and infrastructure to the web only to process code that is written for a so called Web Compatible Runtime and that is not logical
at last that is my observation we should stop to produce stuff that blocks other stuff and start all working like the linux community together to improve browser and whole Web Interop if NPM and NodeJS not soon gets a part of that and not the main blocker i see no future for that.
we should not reinvent the wheel and in the browser is simply no JSON import that's the current state and adding that will make nothing better it will even make it more bad. Overall you can do only one thing with Data it is ruin it.
so lets stop ruin data and create useful ways to run software under today assumptions.
Yes, it is.
Your comment has a bunch of statements i'd at worst call inaccurate, at best unevidenced:
- "most people are switching to yarn lock" can you cite your source for this?
- "with good reason" what reasons are those? either way, yarn.lock is a lockfile that only works in concert with package.json, so it seems irrelevant.
- "NodeJS internal already produces package-json.lock" no, it absolutely does not; npm produces
package-lock.jsonand this is also a lockfile that can only function in the presence ofpackage.json - You can already have a lazy loading ESM entrypoint, using
import()- in basically every environment. - web interop was never a thing before node, and bundlers are how we got web interop.
- browsers do, in fact, have JSON import via import assertions, so this is incorrect as well.
To be frank, all of this seems like you have a confusingly explained }personal vendetta/agenda. The purpose of this working group is to make it easier to maintain npm packages for use in node. Specifically, and from the readme:
Repository for discussion on how to help ensure baseline maintenance and ability to safely use key packages in the ecosystem with current Node.js versions.
I think this should be closed, and I'd encourage you to take this passion and figure out the appropriate venues to discuss it, so you can be more effective. I unfortunately don't have any suggestions besides the WinterCG group, which you're already aware of.
@ljharb i do not know what is missing but look into projects like stackblitz and vite or the turbo bundler that are in fact the largest parts of the ecosystem do you agree with that?
I do not know how you rank your ecosystem relevance i rank based on the final result if i do not need something to come to the final result it is not relevant is that correct defined?
they claim stuff like reduction of build time via skipping nodejs and the whole ecosystem by design the main goal of all projects is to transform away from NodeJS core principles do you see that or do i need to expand context?
also the typescript movement is only about moving to typescript so away from nodejs while trying to keep up with package.json quirks via node resolve algos.
in a typescript project a tsconfig replaces the package.json and can eventual reuse it partial
Vite
Most used bundler under the most used Frontend Frameworks using rollup under the hood
Stackblitz
A Web Platform that has created a WASM Polyfill of the NodeJS API without the ability and compat for nativ modules so only used to run npm also includes a minimal linux fake tty to allow usage of node commands like npm and node cli
No, I don't agree with that, unless you have some kind of source beyond your perception of hype.
Using TS, or bundlers, or the frameworks you've mentioned, all involve node and are not about moving away from node at all - its core principles or any other part of it. tsconfig.json in no way replaces package.json - have you even used TS?
@ljharb i am in fact one of the most skilled when it comes to Typescript Resolve Issues and internals with that. But i guess i see as your only a tool user you do not understand what happens inside the code your a blackbox fan
It seems like this has devolved to insults. Is there anything further to discuss that's relevant to this repo's purpose? If not, I'll close.
It is not insulting truth hurts it hurts you it hurts me do not take it personal i am learning your learning
I need to learn how to convince some one who has your patterns of solution solving methods.
can we maybe have a live in person meeting some where we are in many comitees together we could make a date and add it to the agenda?
Out of my view when i can learn what makes you blocking the effort of overall code reduction i can more fast convince people that have the same mental concepts.
That is important as this is a IT Issue i do not know which context and which points i need to minimal transport to convince and show the benefits i need to even reduce the benefits to be on point.
imo the npm package ecosystem has had the greatest positive impact on overall code reduction, and much more importantly, code correctness, by maximizing the reusability of code. I'm not going to be convinced with any argument that starts out failing to acknowledge node and npm's historical and continuing role in the success of the JS ecosystem.
Did you isolate what are the points that made NPM great?
It is the integrity checking the specifier lookup resolve thats it. everything else like using tar.gz http git is on top of that in fact git implements the same as NPM does internal. but in a more opinionated way.
This repo isn't the place to discuss this, so I'm going to close it. Please stay on topic when posting in a repo.