Modules: Name of potential 'type' option might be confusing for 'types' package.json field

[DanielRosenwasser]

Something I realized with type potentially being a field in package.json is that it might be slightly confusing for TypeScript users.

When TypeScript tries to import a package, much like Node.js looks to resolve a .js file from a main field, TypeScript will try to resolve a .d.ts file from the types field. Do we have any concerns here?

[devsnek]

node doesn't know that typescript exists, it seems like a non-issue to me.

[addaleax]

@devsnek I don’t think this was a question about a technical conflict, and more a programmer ergonomics question. (i.e. what the Node.js binary knows doesn’t really matter for this concern.)

[zenparsing]

It seems like it would be a confusing naming situation, especially if there are cases where there might be both "type" and "types" in the same package.json.

[devsnek]

@addaleax sorry, clarification: because node has no concept of typescript, i don't think we need to take the burden of considering how node interacts with typescript.

[DanielRosenwasser]

because node has no concept of typescript, i don't think we need to take the burden of considering how node interacts with typescript.

This might be a theoretically reasonable stance, but Node doesn't exist in a vacuum. The reality is that this isn't an ideal scenario for many developers. We have already discussed potentially choosing a different name for the setting, so if we would like to avoid developer confusion maybe we should pursue that.

[GeoffreyBooth]

I understand the desire to not be so similar to "types", but I really like the symmetry of "type" matching browsers’ <script type="module">. I think "type" is the best name for it.

[SMotaal]

As an on/off TypeScript user, I think that it will be easy to spot the difference here. Putting "types" in packages has already require a conscious effort in the first place. Seasoned TypeScript users will recall a time where "typings" was the field used to designate the types entry of the package.

Honestly, imho someone knowing enough to put "types" will be at a comfortable enough level to welcome and appreciate "type" and be seasoned enough on both fronts to not allow such a typo to evolve into an issue in TypeScript, Node or even NPM.

TypeScript taking an extra validation step when running tsc in a package scope that is not a node_modules/… package (ie dev) to point out that types: "module" does not exist and warns appropriately is sufficient — more so if tsc maybe opts for making the extension explicit (been a while, can't recall if it was ever optional).

We ❤️ TypeScript

[goodmind]

Btw typescript still supports "typings" field, maybe you can remove "types"?

[weswigham]

Btw typescript still supports "typings" field, maybe you can remove "types"?

Nope. That'd break a ton of existing packages with types, which we have no intention of doing. However, what we _can_ do is special case an error message for when "types": "module" or "types": "commonjs" and it fails to resolve, outputting something like Did the package author mean to say "type": "module" instead?. It's not perfect (you don't usually have direct control over a dependency), but we can try and deal with it - it won't help anyone using older versions of TS though.

node doesn't know that typescript exists, it seems like a non-issue to me.

I don't think we're considering using the "module" field at all since it's already in use in the community for something, no? There's no _direct_ conflict here, so so long as everything's in order, we should all be good, but it's worth considering the extra debugging burden that may be put on authors when things do go wrong.

As I said, it's certainly not the end of the world and we can do some mitigation work ourselves, but it's also not necessarily usability problem-free, so is worth at least putting a moment of thought into. For example, on the TS side, we can issue a warning at compile time if a types field resolves incorrectly (or if the type field is an invalid value), but what if an old version of TS is used or the error has been suppressed by some miscreant?

It may be worthwhile for node to have a similar helpful error at _runtime_. If a .js file entrypoint fails to parse, and its containing package.json has a "types": "module", pointing out the typo explicitly in the error could be worthwhile. In addition, if when validating the "type" field it is an unknown value that happens to be a path to a file on disk (or specifier mapping to one), like "./dist/index.d.ts", it might be worth calling out that you probably meant to write "types" and that "type" is for specifying module formats.

[SMotaal]

@weswigham there is no harm in exploring this idea, but to be entirely honest (speaking purely as an observer) such a decision would likely see resistance from the premise that while TypeScript projects with a package.json may and likely will rely on Node.js at some point, not every project with a package.json will always rely on TypeScript. (this is a base premise for more along those lines that will likely unfold)

Sorry — I am being very honest and objective and can be absolutely wrong but think it is only fair to raise this right here to try to make the best decisions all around, thoughts?

[SMotaal]

If we are exploring this:

1. Can we generate data on the usage of "types" in pjson.

2. Is there precedence of having a particular field be conventionally restrictive, ie if a pjson had a types that was not intended for TypeScript, is there procedures to make it that this would be an error (human or otherwise) when pjson is handled elsewhere, including Node.js at least?

[DanielRosenwasser]

Sorry — I am being very honest and objective and can be absolutely wrong but think it is only fair to raise this right here to try to make the best decisions all around, thoughts?

I know you only have good intentions, and I really appreciate your empathy here. 🙂

TypeScript projects with a package.json may and likely will rely on Node.js at some point, not every project with a package.json will always rely on TypeScript.

Pragmatically speaking, this is true, though I don't know if I think that's the right rationale for making a decision here.

I'm not trying to have us consider a worse name - just a different one. If all the options on the table feel worse, than type is probably acceptable. If we picked a name that was as acceptable as type, then regardless of if TypeScript no longer exists in 5 years, or if it rises from 62% of usage of npm users, we're likely no worse off.

[SMotaal]

@DanielRosenwasser

Based on my own somewhat educated guess on what "nuanced" implies in that post, an argument to be made about the relevance of package:types to a TypeScript and non-TypeScript "package consumer" alike (ie node_modules/…).

There is good argument in general that to some extent(s) to be quantified the concern being a developer-facing issue. More explicitly, to both be triggered by and be reasonable-to-mitigate for an actual "package author" or "package publisher" than other developers with varying familiarity of TypeScript itself — ie warnings making sense to people with different focuses on a project.

Can we find a different brainstorming opportunity towards some reasonable proposals?

[GeoffreyBooth]

Can we close this issue? I think it’s safe to say that there’s no obviously better name that everyone agrees on, and the workarounds mentioned above (having some logic that checks for obvious typos like "types": "module") seem reasonable to me and likely to catch most mistakes. We can always revisit if it turns out that users express a lot of confusion or difficulty when trying out the new --experimental-modules.

[SMotaal]

@DanielRosenwasser I think the meeting for upstream feedback re type would be a venue for related discussion.

[MylesBorins]

I'm going to close this for now, it doesn't seem like we are changing type. Please reopen if this was done pre-maturely