Main sugar

[guybedford]

I really like most things about this proposal, and while the main syntax is consistent, it would still be nice to have a user-friendly sugar for this.

Shall we really get in to bikeshedding a new main name here?

Alternatively, do we really need dual mode package mains? Because if we dropped that we could allow the "main" field to stay and mean the main for whatever the mode of the package is.

Thoughts welcome.

[jkrems]

I really like most things about this proposal, and while the main syntax is consistent, it would still be nice to have a user-friendly sugar for this.

Not sure I follow here - can you elaborate on what you mean by sugar?

For context, the proposal already allows to specify a single export by setting exports to a string:

For modules that desire to export only a single entrypoint, e.g. import request from 'request', the "exports" key itself can be set to the entrypoint:

{
  "name": "request",
  "version": "0.0.0",
  "exports": "./request.mjs"
}

EDIT: To clarify, in the above "exports": "<str>" is just sugar for "exports": { "": "<str>" } and has the exact same semantics.

I think having it sometimes be exports and sometimes be main seems confusing. Or are you suggesting to drop the use of exports in favor of reusing the main field for everything?

[guybedford]

Ah I missed that there was that "exports": String sugar... that sounds useful.

I guess it's mostly an aesthetic argument at this point about the "" case.... say you were new to Node.js and saw this in the package.json, perhaps it would be confusing?

I think having it sometimes be exports and sometimes be main seems confusing. Or are you suggesting to drop the use of exports in favor of reusing the main field for everything?

I can get behind exports actually if we have the string case.

Maybe we should be bikeshedding the main key to use then further in "exports"?

[jkrems]

Maybe we should be bikeshedding the main key to use then further in "exports"?

Yeah, the empty string is somewhat awkward. IIRC originally it was:

{
  "exports": {
    "default": "<str>"
  }
}

The empty string was chosen mostly because it gets us around reserving any "real" values and because it's compatible with the "each key is just concatenated to the package name" rule. I think either empty string or a magical keyword works. I'm -0.5 on "main" as a key name because it might make people think they can point to a CommonJS file or that all possible top-level main patterns would be supported etc..

[guybedford]

Maybe we should just got back to default? Reserving a real value really doesn't seem that bad to me - we can just throw an invalid package specifier for any import 'pkg/default'.

[jkrems]

Should we disallow the empty string? Or would "default" be defined as sugar for the empty string? I'm leaning towards the latter because currently the empty string behavior falls naturally out of the basic logic and we'd have to go out of our way to prevent it.

[guybedford]

I would prefer to disallow the empty string so that it is simpler to explain to users. Even though it’s algorithmically an exception it wouldn’t be seen that way by most users if they’re used to ‘default’. On Wed, 05 Dec 2018 at 16:46, Jan Olaf Krems [email protected] wrote:

Should we disallow the empty string? Or would "default" be defined as sugar for the empty string? I'm leaning towards the latter because disallowing the empty string adds an exception to the algorithm without necessarily adding value (e.g. currently the empty string behavior falls naturally out of the basic logic and we'd have to go out of our way to prevent it).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jkrems/proposal-pkg-exports/issues/16#issuecomment-444510140, or mute the thread https://github.com/notifications/unsubscribe-auth/AAkiyvlrxP9l2twgLGNL4ol88KMB4ryHks5u19xRgaJpZM4ZChdR .

[GeoffreyBooth]

To be honest I think the empty string makes more sense. It’s easier to understand string concatenation than a more complicated “sometimes it concatenates unless it’s a special keyword.” If you’re going to have a keyword, I think you need a more complicated object like:

"exports": {
  "root": "./index.mjs",
  "deep": {
    "/foo": "./foo.mjs"
  }
}

The other issue is that if it’s not string concatenation, or sometimes not string concatenation, then would the left hand side always need to start with /? It just gets more complicated.

[guybedford]

@GeoffreyBooth it's great that you're thinking in terms of the Kolmogorov complexity of the spec, but we are optimizing for user experience + spec complexity, not for one over the other.

[GeoffreyBooth]

I was only thinking in terms of UX 😄and how I would explain it in potential documentation. I think “left hand side is string concatenation, right hand side is URL” is as good and easy as we’re likely to get. I appreciate that an empty string is ugly, but I don’t think a magic keyword (or the example I just posted above) are better.

[jkrems]

Is this relevant again now that dot-main is seemingly back on the table? Or did we get used to the notion of dot-main as the syntax in exports?

[guybedford]

I think this is more of a modules issue than being directly related to this proposal at this point. Whether this proposal implements the dot main or not seems separate too.