Currently this config disallows adding extensions like .js and .jsx in import path. This contradicts node.js's plan for esm that extension are mandatory.
Mandatory file extensions
A file extension must be provided when using the import keyword. Directory indexes (e.g. './startup/index.js') must also be fully specified.
This behavior matches how import behaves in browser environments, assuming a typically configured server.
That's not node's plan - I'm a member of the modules group. That's just the current default implementation. Extension resolution is shipped behind an additional flag, and my hope is that it will be enabled by default prior to unflagging node's native implementation.
Regardless, prior to node's implementation being unflagged, its flagged implementation should have no bearing whatsoever on any ecosystem decisions, since for all intents and purposes, node's ESM system does not exist yet.
Should this issue be reopened given the newly published node 14 esm implementation does require file extensions?
@FergusonSean unfortunately yes, node v12.7+, v13.7+, and v14+ have an ESM implementation that does not do resolution. Extensions (on relative files, or packages without "exports" only) are required when using import.
However, this guide currently recommends using babel and not native ESM, and even were it to recommend that, the relevant linting tools (eslint-plugin-import, in particular) does not yet support ESM or "exports" resolution - so the time to make changes is still a ways off.
Most helpful comment
That's not node's plan - I'm a member of the modules group. That's just the current default implementation. Extension resolution is shipped behind an additional flag, and my hope is that it will be enabled by default prior to unflagging node's native implementation.
Regardless, prior to node's implementation being unflagged, its flagged implementation should have no bearing whatsoever on any ecosystem decisions, since for all intents and purposes, node's ESM system does not exist yet.