The term "native module" dates back to some of the oldest code in the code base (e.g. f39fdf2), within the context of Node.js core it usually refers to modules that are native to Node.js (e.g. fs, http), but when communicating with people who don't work on this part of the code base, I often myself clarifying what it is (that is, it's not the native addons, or the C++ bindings) and using the term "builtins" instead to avoid misunderstanding. In addition there are more references to "built-in modules" or "builtin modules" than "native modules" in doc/api (and in napi.md and esm.md "native modules" actually means addons, which adds to the confusion). At this point I suggest that we rename "native modules" to "builtins" (or other variants like "built-ins", "builtin modules") in the code base when referring to these modules to avoid the confusion, and leave the term "native modules" to addons (and better yet, just always call them addons, AFAIK that's the more widely-recognized term for that).
The term "native module" dates back to some of the oldest code in the code base (e.g. f39fdf2), within the context of Node.js core it usually refers to modules that are native to Node.js (e.g. fs, http), but when communicating with people who don't work on this part of the code base, I often myself clarifying what it is (that is, it's not the native addons, or the C++ bindings) and using the term "builtins" instead to avoid misunderstanding. In addition there are more references to "built-in modules" or "builtin modules" than "native modules" in doc/api (and in napi.md and esm.md "native modules" actually means addons, which adds to the confusion). At this point I suggest that we rename "native modules" to "builtins" (or other variants like "built-ins", "builtin modules") in the code base when referring to these modules to avoid the confusion, and leave the term "native modules" to addons (and better yet, just always call them addons, AFAIK that's the more widely-recognized term for that).