should import { getter } from 'cjs-mod' work?

[dnalborczyk]

not sure if this is intended, or a bug.

related to: from #516

I was originally wondering if it should be possible to import promises (which currently is a getter) from fs.

// index.mjs
import { promises as fs } from 'fs'

node --experimental-modules index.mjs
#(node:57314) ExperimentalWarning: The ESM module loader is experimental.
#file:///test/index.mjs:6
#import { promises as fs } from 'fs'
#         ^^^^^^^^
#SyntaxError: The requested module 'fs' does not provide an export named 'promises'
#    at ModuleJob._instantiate (internal/modules/esm/module_job.js:80:21)

node -r esm index.mjs
# file:///test/index.mjs:1

#SyntaxError: Missing export name 'promises' in ES module: fs
#    at file:///test/index.mjs:1

@jdalton after some research I saw your comment that this was planned for node: nodejs/node#20504 (comment) is this still the case and a bug in node and/or esm? or was it decided against to allow named imports of cjs getters?

someone also did mention that it did work prior node v10.2 with esm nodejs/node#20504 (comment)

[jdalton]

Getters should work. The issue with fs.promises is that it's non-enumerable and so should not show up in the ns object. In fact, it doesn't show up in our ns properties when using Object.keys which means it's leaking in through our proxy wrapper for it.

[dnalborczyk]

aaaah, ok. so only enumerable getters should work. that makes sense (how would esm otherwise know it's there), but it's also unfortunate (for esm and node users)

I'm kinda thinking that node should have separate exports for any promises, a la fsPromises, dnsPromises or something like that -- maybe even a separate module a la import { copyFile } from 'fs-promises'. otherwise one always has to use a 2-liner with destructuring, or use the dot notation to get a reference.

[dnalborczyk]

uh, I guess Reflect.ownKeys would know ... 😕

JavaScript is killing me!

[jdalton]

The enumerable bit is a way to avoid triggering getters which may be for deprecations or experimental APIs. The way ESM is handled in native node they must iterate over these properties before running their ESM scaffolding for them. This would trigger deprecation warnings for APIs that aren't even accessed by the user. With esm I can avoid that and iterate over them a bit later (on demand) but I try to match native's limitations here. In this case fs.promises is still considered experimental so is non-enumerable and bypassed for --experimental-modules. One experimental thing doesn't depend-on or guarantee-to-work-with another experimental thing.