Optional Chaining support

[rwproj]

with latest node (13.8.0)

// example.js
let a
a?.b

works with when running node --harmony

but doesnot work with esm: node --harmony -r esm example.js

// example.js
import path from 'path'
let a
a?.b

a?.b
  ^

SyntaxError: Invalid or unexpected token
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1171:10)

[DaniloBarros]

Are there any updates on this issue?

[Taranys]

Some update on this issue, I tried on the last NodeJS version (14.1.0) because you don't need --harmony flag anymore. But it still not working :disappointed:

Without esm, optional chaining works fine.

[markamccann]

This is too bad. Same problem with nullish coalescing in Node 14+

[brettz9]

FWIW, until esm may support it, it's working for me to use @babel/register with the plugin @babel/plugin-proposal-optional-chaining (and I also needed the plugin babel-plugin-transform-import-meta for import.meta.url which, unlike esm, babel/register doesn't understand as well as babel-plugin-transform-async-to-promises to avoid regenerator-runtime for async).

[canonic-epicure]

Just stumbled on this issue too. Looking forward for the fix.

[twixr]

Same issue.

id: options.params?.id
                   ^
SyntaxError: Invalid or unexpected token
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1220:10)

The reason I use esm is so that I don't have to build my code using Babel. So using babel plugins isn't an option for me.

Node v14.3.0 with and without --harmony flag

[jdalton]

I'll update the parser. Thanks!

[matthewharwood]

@jdalton will this parser update include nullish coalescing? 🙏

[hroland]

@jdalton Excited for this one!

[matthewharwood]

@jdalton Any update on when we can expect this?

[jsg2021]

It works after updating acorn.

[prashantpalikhe]

Awesome! Hope this gets released soon 👍

[patspam]

Any ETA on this?

[jsg2021]

It's fixed in my PR. #883

You can use it or fork it. I'm not a maintainer, so I can't merge/publish.

[luluhoc]

Can you please update the parser?

[jsg2021]

@luluhoc there is a PR waiting to merge.

[hroland]

We've been using @jsg2021's PR in production for 4 months now without an issue! 🙌

[chrisspiegl]

May be considered #offtopic: but how is this not supported yet? Please, pretty please merge the PR as it seems to be working for many.

[loilo]

@chrisspiegl Maybe this does answer your question. 😉

[aksel]

@chrisspiegl Maybe this does answer your question. wink

Far out.

So esm does not have a maintainer?

[loilo]

So esm does not have a maintainer?

I can't say for sure. JDD had obviously done most of the housekeeping in this repo. The standard-things project has multiple members, but

1. I'm not sure about their permissions for individual repos.
2. I'm not sure about their responsibility for individual repos.
3. They probably are pretty busy themselves.

🤷‍♂️

[twelve17]

So esm does not have a maintainer?

If the recent activity is an indicator, looks like the parachute landed in the Salesforce jungle 😉

[CleyFaye]

I believe it's worth noting that ECMAScript modules support is now considered "stable" in node 16, and after a quick glance seems like using esm would be redundant (that is, if you can blindly upgrade to node16).

[twelve17]

@CleyFaye indeed. Though my main hangup is testing with mocks.

[canonic-epicure]

More over, EcmaModules support is available in Node 12 already

[chrisspiegl]

That seems true that with V12+ and especially with V16, you have pretty good support for ECMAScript modules. However, the ESM module here gave a lot more 'leeway'. Moving to a clean implementation was a good chunk of work for me, but at this point I got rid of ESM in my code base at least.

[smcenlly]

We needed this issue fixed so have forked and published our forked repo if anyone needs it.

[jdalton]

Ah wallaby! @smcenlly. I should revisit this stuff.

[alcalawil]

This code fails. Any import word found in the code will make it fail:

node -r esm script.js

// import smart things from china
const xx = process?.version; console.log(xx)

[cezarcarvalhaes]

We needed this issue fixed so have forked and published our forked repo if anyone needs it.

Thanks for this @smcenlly! Unfortunately I'm still having issues with it. I was using esm to allow mocha to use esm imports, but using esm-wallaby gives me the Cannot use import statement outside a module error, which the original esm package solved for me. (Unfortunately the original esm package interprets optional chaining as syntax errors though).

I'm running node 14.17.

***EDIT The above issue was related to Mocha, not esm-wallaby. Thanks again for publishing this!

[toastyghost]

Fix in PR a year and a half ago and STILL not merged?

[chrisspiegl]

@toastyghost As others have pointed out, we should consider this project dead until proven differently. So it'd be best to move forward and not depend on esm any more if at all possible. All things considered: Node has come pretty far and is now supporting most of the ESM features natively (if you are able to update to the latest releases).

[canonic-epicure]

Yup, native ES modules support was added in Node 12.~20

[flopail]

Hi everyone, :)

I had the same problem about optional chaining operator (with node >= 14 ) when I did: node -r esm path/to/my/file.js I solve it by installing esm-wallaby dependency and by using it like this: node -r esm-wallaby path/to/my/file.js

In my case, it also fixes nullish coalescing operator (??).

I hope it could help. Have a good day!

[CleyFaye]

Note that node now have decent support for modules built-in, there is no real need for a dependency anymore.

[Nantris]

Node's support for built-in modules is still god-awful. You have to jump through all sorts of hoops and define things at the project level to get them to work. I'd really like to have optional chaining support with node -r esm

[CleyFaye]

Can you elaborate on this? As far as I know, you only need either setting "type: module" in your package.json or name your files .mjs, both options providing great compatibility with all the tooling around (like bundlers). I'm curious at what other troubles can arise at this point.

[Nantris]

Some tooling doesn't do well with type: module and having to rename all of your files to .mjs is sort of madness, no? Not to mention that things like import * from './foo' will work if the file is foo.js but will fail if it's foo.mjs with all the tooling I've used so far. I'm sure that's not universal, but it makes a lot of headaches.

[CleyFaye]

I see. I didn't encounter any situation that needed renaming everything; most bundler just accept whatever you throw at them, and not having the full file name is not really on the table either.

But I see how some workflow might require that. Still, it is likely that esm never gets an upgrade. It might be wiser to look into updating these tools too.