Is NPM a universal tool?

It may seem like an obvious query, but there is a great divergence between the content available on the web and the npm documentation itself with respect to the current reality and, in my opinion, this part affects what is known as javascript fatigue.

To explain better, I'll quote the readme of [npm package in npmjs.com]

Contrary to popular belief, npm is not in fact an acronym for "Node Package Manager"; It is a recursive bacronymic abbreviation for "npm is not an acronym"... The precursor to npm was actually a bash utility named "pm", which was the shortform name of "pkgmakeinst" - a bash function that installed various things on various platforms. If npm were to ever have been considered an acronym, it would be as "node pm" or, potentially "new pm".

Similarly, in the "about" of the official page, there is no mention of having a relationship with Node (except for the invitation to study at nodeschool).

Despite all this, as the documentation is read, the direct relationship of terminology associated with packages for Node becomes notable, which may make sense from a historical point of view, but today NPM contains in its There are many packages created for other execution environments, such as the browser or even DENO.

DENO, for its part, is working hard to stabilize this operation, as explained on its official site.

In this sense, and taking into account the reality of Javascript today, regarding everything that can be done with the language and the platforms it covers (IoT, Mobile, DENO, BunJS, NODE, Browsers, etc.), I think it would be It is convenient to be able to update the documentation to understand if NPM works with cross-platform packages or if it only has the focus of following the guidelines of packages that can be published for NODE.

Defining what is the purpose and objective of NPM today I think is crucial.

Understanding that NPM's view is the reference for javascript packages, my suggestion is to improve the documentation, and make the necessary adjustments so that it handles generalized information, which can be useful for the development of any package, regardless of the environment in which you work.

To better exemplify it,
If we talk about Node itself, today it is somewhat outdated with respect to what can or cannot be defined in the package. They are, for example, the “exports” entry point and the conditional exports proposed by node and already taken into account by others. tools and platforms are not included here, I think that unifying criteria so that the community can understand whether or not to use NPM as a reference for the definition of packages is something crucial nowadays.

Review the linked npm README, npm’s “About packages and modules” page, and Node’s packages documentation covering exports and conditional exports. First determine the documentation scope and which runtimes are covered; done means the relevant npm guidance clearly explains its relationship to Node and other JavaScript environments.