Package & Module sub-terms for Agnostic Consumers

[robpalme]

Add sub-terms of Agnostic Consumers:

• Agnostic Package Consumers
• Agnostic Module Consumers

The immediate reason for adding these terms is to help separate the debates around:

• interop across package boundaries - which maybe less controversial
• interop within a package - which appears to be controversial

I'd welcome feedback on whether different terms would be clearer, e.g. perhaps inter-package interop vs intra-package interop

[demurgos]

This issue is about the different possible import specifiers. Following the various discussions and proposals, I think that clarifying it is important but it may more complicated.

Here are the different cases where the proposals can diverge:

• relative specifier (starts with "./" or "../") VS bare specifier
• simple bare specifiers VS deep bare specifiers: "pkg" VS "pkg/deep"
• resolved module outside the package boundary or not: Even with relative path, you can use things like "./foo", "../../../../outside/foo", "./node_modules/lodash" (is it inter or intra package?)
• specifier pointing to a directory containing a package.json or not (more relevant than simple bare VS deep bare? eg. "@babel/types" has a package.json: you're not grabbing individual files inside, unlike "@angular/animations/browser")

I had a comment somewhere else that I find "agnostic import" more fitting than "agnostic consumer" because the "lack of knowledge of the dependency implementation" is defined for each individual import (static ES import / dynamic ES import / CJS require), not at the module level (and to me "consumer" strongly implies the "consumer module"). A consumer module can mix agnostic or not imports.
Framing the terminology around imports (instead of consumers) would allow to more naturally use qualifiers describing the specifier: "agnostic relative import", "agnostic deep bare import", "agnostic extra-package import".

At the moment, Node has no concept of package boundaries (there was a module-related PR to introduce it). It seems that the most relevant distinction is if the specifier points to a file, a directory with "package.json" or a directory without "package.json". The relative/bare distinction just decides if we walk the parent directories looking inside "node_modules" or not. Since the most common use case for specifiers pointing to a file are "intra-package" imports and for specifiers pointing to directories with "package.json" are "inter-package" imports, I'm fine with using it as a shortcut, but it must be clearly understood as so.
Defining the terminology with "package" may also be imprecise in the case where a file is a standalone script without any package.json around: are its relative imports "intra-package" despite there being no package at all?

Maybe something like:

• "agnostic package import": The specifier points to a directory directly containing a "package.json"
• "agnostic module import": The specifier points to a file or directory without "package.json", regardless if it crosses eventual package boundaries. Proposals involving package-scoped config are on the implementation side so irrelevant to agnostic imports (maybe ?).

---

Edit: So overall I got confused while thinking about the issue but agree with this PR. Sorry for causing noise about import/consumer.

[ljharb]

Please let’s not use the word “import” to mean anything except “the keyword used inside ESM”

[bmeck]

We can use "loading" maybe?

import() is available in all grammars so I'd be reluctant to tie it to ESM though since we shouldn't distinguish import() from import statements.

[ljharb]

All the more reason to avoid overloading the word. Loading is fine but connotes loaders specifically; i think “consuming” might work.

[demurgos]

Edit: Sorry, this message is just causing noise about another terminology point. I definitely agree with the package and module qualifiers as defined in this PR.

---

#119 (comment)

I consider the term "import" to be ambiguous because it depends on the context. I see two possible interpretations:

• ES import: A static import statement or dynamic import() as defined by the ES spec.
• CJS or ES import: Either an ES import or a require (represents the abstract concept of importing something regardless of the concrete import mechanism)

I agree with you that it's also a point causing confusion, but I don't feel "loading" or "consuming" are the best terms to mean "any kind of import mechanism". It probably deserves a separate issue, but in the context of my previous comment I used "import" to mean "any kind of import mechanism". I prefer people to clearly say "ES import" or "CJS require" when the difference matters, and just "import" when the difference does not matter. This is consistent with other cases where a term alone has the broader meaning and you use qualifiers to reduce its scope.

I also think this fits better with the terminology I propose:

• "agnostic package ES import": A static or dynamic import for a package, without knowledge of its implementation
• "agnostic module import": Any kind of of import (ES import or CJS require) for a file or simple directory, without knowledge of its implementation.

[robpalme]

My summary so far on the feedback from @demurgos @ljharb @bmeck is that:

• the package & module qualifiers and their definitions have no objections; in fact @demurgos comes to the same conclusion
• we're not sure what noun to pick: consumer vs importer vs loader

So far I agree with @ljharb that using import in this context is misleading because it falsely implies we're talking exclusively about the import or import() forms.

Whilst I don't think we need to reserve the term load exclusively for things that involve loaders, in this case where we are using loader as a noun, it's highly ambiguous, e.g. is agnostic package loader referring to a module that loads packages agnostically, or is it referring to a loader that deals with packages agnostically?

Hence I come back to the original agnostic consumer as the best way to talk about something that loads things agnostically.

[SMotaal]

@robpalme was this included in #158 before it was finally merged? Can we close this if so?

[GeoffreyBooth]

This has conflicts, but I’m not sure we need this PR at this point. Can this be closed?

[robpalme]

@GeoffreyBooth At this point I think the conversation has moved onto concrete proposals so this refinement of terminology is no longer needed.