`engines` and non-Node usage

(Brett Zamir) #1

Per https://docs.npmjs.com/files/package.json#engines

If you specify an “engines” field, then npm will require that “node” be somewhere on that list. If “engines” is omitted, then npm will just assume that it works on node.

  1. If the intent is to suggest that whether you include or don’t include “engines”, Node support is expected, I think this statement should instead end with the following to be more clear: “npm will just assume that it works on any version of Node.” It would also help to mention that there actually is no requirement that Node be on the list; at least I have had packages install without “node” there.

  2. However, I am hoping that is not actually the intent, or that you would be willing to change the intent. Because I think there ought to be a way to at least indicate that one’s package does not actually work in Node (at least not without someone settings things up with jsdom or what not). This should be of convenience to Node users, who will not be bothered with packages that don’t support Node. (On top of this, it would be ideal from my perspective and probably the increasing number of us using npm for non-Node projects (given trends and bower’s essential deprecation)), if there can be a however open-ended mechanism mentioned that the browser or some other non-Node environment could leverage to indicate their own level of support e.g., by extending engines with custom properties, then users of packages working in other environments could have a way to discover support).

I realize this is the Node package manager, but as people are using it for client-side code as well, this seems of relevance, even if you are not specifying client-side use.