Is NPM a universal tool?

[jircdev]

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.

[ljharb]

What problem exists right now that you think doc clarification would solve?

[jircdev]

What problem exists right now that you think doc clarification would solve?

The NodeJS docs have docs about exports and conditional exports and how to set different target platforms as "deno", but NPM does not list anything about it.

I think you can agree that if someone wants to know how is the structure of the package.json to build one, for sure, will think firstly in npm docs rather than nodejs docs. I thought to contribute to upgrading the package.json page and make a pull request, but first of all, I want to really know if NPM brings support to cross-platform javascript packages or if definitively is based only on NodeJS.

The "exports" entry point is a very interesting characteristic that let developers define which file of the package should be consumed per target platform or module resolution system, which is very useful. Also, this way replaces the "folder as modules" with sub-package.json files too.

This is one example.

[ljharb]

Why would npm list anything about fields that it doesn’t pay attention to?

[jircdev]

Why would npm list anything about fields that it doesn’t pay attention to?

Well, first of all, thanks for reading. This is my question. Is NPM a cross-platform package manager or not? In fact, if the way to define the packages located in npm should follow a standard, who should define it?

I'm asking because I think it's a very good idea to try to move towards a standardized way of defining packages. I don't understand when you say it doesn't pay attention if every tool in the chain that works with npm (like webpack, unpcgg, etc.) already does.

I think it's not clear enough how a developer can create a package that can be accepted by all current development tools and this causes a lot of incompatibilities. Why do you say that npm doesn't pay attention to the "exports" field but instead talks about "submodules", which is a deprecated node structure?

[ljharb]

It is, but that doesn’t mean it would be a scalable or good idea for it to list details of every platform that happens to use it. Node should and does define the way it interacts with npm packages, same as Deno etc.

At this point and for the foreseeable future, the quickest way to make a universal package is to make a node one - other tools will likely choose to interoperate, and if not, then it’s up to them to define the differences.

[hello-beyond]

So if my understanding is correct, the creator of a package that has implementations of modules whose code varies depending on the execution platform (node, browser, deno, .. and any other that may exist in the future), and that If they want to ensure a good implementation, they should be guided by the nodejs docs. There, the exports and conditionals seems to be well documented, and a reference is made about the coordination of the community.
NodeJS - Community Conditions Definitions

It is clearly said there that new platforms can implement other export conditions, and it is indicated on that page that new definitions can be added to the existing ones (node, deno, browser, etc) by creating a pull request to that section.

If that is the case, I think it would be nice if NPM could make a reference in its documentation to the nodejs link, so developers who want to publish universal isomorphic packages could know which specification to follow. It may not be so clear that the nodejs site is the reference for universal packages, as nodejs is one platform among others.

[ljharb]

it’s not “one”, it’s “the” - it’s the original and the one npm requires. for better or worse, node will likely always be the primary platform among others, and for the foreseeable future at least, should be the expected default (as is npm itself).