Proposal: Support loading package by own "name"

[guybedford]

This has been discussed before, but I think it's a good time to consider it now.

A very common problem in Node.js applications is the backtracking problem where you have to always reference modules through ../../components/name.js.

Since we're loading the package.json when checking the module boundary, we thus also know the package.json "name" that any given module is in.

What we could do is support loading a package by its own package.json "name" by default.

This would allow conventions where users just set a package.json name and can then use import "pkgname/components/name.js" instead.

It's a very small feature that seems like it could solve a pain point quite elegantly.

Would be nice to discuss this further at the next meeting.

[ljharb]

It'd be great to provide this feature - in both CJS and ESM (i wouldn't want it in only one of them) - but this would conflict with someone manually putting a folder in node_modules with their same package name. I think we'd need a prefix that couldn't possibly be already valid - like ~ or something.

[devsnek]

definitely a cool idea, but I think it's out of scope of this group

[GeoffreyBooth]

definitely a cool idea, but I think it’s out of scope of this group

Why? Resolution is part of modules.

[ljharb]

Modules should have the same resolution as CJS, or at least a subset - but not a superset. This is a feature that applies to CJS as well, and it would be a bad idea to add it to ESM without also adding it to CJS.

[robpalme]

@ljharb You've mentioned this approach a few times now. What is the rationale for keeping CJS up to date with the ESM features?

It seems odd to try to update the old system to keep feature parity with features of the new system. Potentially it sends mixed messages about the future endorsed practices and places an ongoing tax on the design space.

[ljharb]

CJS isn’t legacy. It’s not “the old system”. It’s one of two first-class module systems that node will be supporting for likely the next decade, if not forever.

Hobbling CJS is not an effective means of encouraging adoption of ESM - and any features that only work in ESM will make migration and interop harder.

[bmeck]

Adding features to one distinct system does not hobble or remove the viability of the other. It is natural for two systems to evolve different directions. We should not try to treat them as the same system and require them to have the same features since they are different both in intent of design and constraints.

…

On Fri, Apr 5, 2019, 10:59 AM Jordan Harband ***@***.***> wrote: CJS isn’t legacy. It’s not “the old system”. It’s one of two first-class module systems that node will be supporting for likely the next decade, if not forever. Hobbling CJS is not an effective means of encouraging adoption of ESM - and any features that only work in ESM will make migration and interop harder. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#306 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOUo0EPkcMj96qRZ8-sT91-qJm0pjn1ks5vd3LmgaJpZM4cdoNc> .

[hybrist]

Saying that the import system must be a strict subset of the require system seems to hobble the former. I do agree that both are and will for the foreseeable future be first-class module systems but both will necessarily have unique features based on their properties and constraints. Just given that require is used in the ecosystem with the very specific semantics it has today means that there's a tiny design space. Accepting that as a constraint for import means import will always be a worse require.

[devsnek]

re my comment, i think 1) both systems can get use from this, but 2) if one doesn't have it, it would be confusing for the other to have it. additionally, if we added it and cjs wanted to support it, we would want to make sure the design was good for both systems. This is why i think the discussion should take place upstream.

[SMotaal]

I think it is fair to note that if we design ESM to meet the requirements of CJS, then we will inevitably be forced to limit ESM's potential — if people don't like a limited ESM they will not use it.

CJS has a legacy, if people want to see it do new things, it is a good thing, because Node.js can decide about any design aspects.

ESM has specs, if people want to see it do new things, they need to make sure it conforms to the specs, and we've witnessed first-hand the complexity in making this happen in a controlled and manageable way.

So can we say that,

we would want to make sure the design was good for both systems

is satisfied if a custom CJS loader can achieve it — then maybe implementing in CJS follows after it proves worthwhile?

[ljharb]

In this case it’s a node-only concern, since ESM has no concept of packages - so no, i don’t think a package-related feature should be built without doing it for both cjs and ESM, where it makes sense (and in this case it makes sense; this is a big existing pain point for cjs in the ecosystem).

[devsnek]

so people are concerned that in trying to bring this feature to both systems, it will be made worse? if that is the case, I would only say you have no way of knowing that's the case, and that users of both systems would appreciate this feature. I'm not saying every feature has to be in both systems, but this one seems reasonable for both.

[guybedford]

Proposal repo created at https://github.com/guybedford/package-name-resolution.

[devsnek]

@guybedford

your proposal seems to be just as viable for cjs as for esm. the dependencies issue listed under cjs affects both.