Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optional Chaining support #866

Open
rwproj opened this issue Feb 6, 2020 · 39 comments
Open

Optional Chaining support #866

rwproj opened this issue Feb 6, 2020 · 39 comments

Comments

@rwproj
Copy link

rwproj commented Feb 6, 2020

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
Copy link

Are there any updates on this issue?

@Taranys
Copy link

Taranys commented Apr 30, 2020

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 😞

Without esm, optional chaining works fine.

@markamccann
Copy link

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

maximelouet added a commit to maximelouet/spotly that referenced this issue May 8, 2020
Update to the latest version of NodeJS to benefit from the latest
improvements and features, notably optional chaining and nullish
coalescing, for use in the API code without Babel.
Use CommonJS in API code as they're more stable than ESM. Get rid of the
`esm` package that provided full support for ESM as it doesn't support
optional chaining (standard-things/esm#866).
Improve export consistency in front.
Use the `babel-eslint` ESLint parser as the default ESLint parser
doesn't support optional chaining yet (!).
maximelouet added a commit to maximelouet/spotly that referenced this issue May 8, 2020
Update to the latest version of NodeJS to benefit from the latest
improvements and features, notably optional chaining and nullish
coalescing, for use in the API code without Babel.
Use CommonJS in API code as they're more stable than ESM. Get rid of the
`esm` package that provided full support for ESM as it doesn't support
optional chaining (standard-things/esm#866).
Improve export consistency in front.
Use the `babel-eslint` ESLint parser as the default ESLint parser
doesn't support optional chaining yet (!).
maximelouet added a commit to maximelouet/spotly that referenced this issue May 8, 2020
Update to the latest version of NodeJS to benefit from the latest
improvements and features, notably optional chaining and nullish
coalescing, for use in the API code without Babel.
Use CommonJS in API code as they're more stable than ESM. Get rid of the
`esm` package that provided full support for ESM as it doesn't support
optional chaining (standard-things/esm#866).
Improve export consistency in front.
Use the `babel-eslint` ESLint parser as the default ESLint parser
doesn't support optional chaining yet (!).
maximelouet added a commit to maximelouet/spotly that referenced this issue May 8, 2020
Update to the latest version of NodeJS to benefit from the latest
improvements and features, notably optional chaining and nullish
coalescing, for use in the API code without Babel.
Use CommonJS in API code as they're more stable than ESM. Get rid of the
`esm` package that provided full support for ESM as it doesn't support
optional chaining (standard-things/esm#866).
Improve export consistency in front.
Use the `babel-eslint` ESLint parser as the default ESLint parser
doesn't support optional chaining yet (!).
@brettz9
Copy link

brettz9 commented May 11, 2020

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
Copy link

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

@twixr
Copy link

twixr commented May 28, 2020

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
Copy link
Member

jdalton commented May 28, 2020

I'll update the parser. Thanks!

@matthewharwood
Copy link

@jdalton will this parser update include nullish coalescing? 🙏

@hroland
Copy link

hroland commented Jun 3, 2020

@jdalton Excited for this one!

@matthewharwood
Copy link

@jdalton Any update on when we can expect this?

@jsg2021
Copy link
Contributor

jsg2021 commented Jul 8, 2020

It works after updating acorn.

@prashantpalikhe
Copy link

Awesome! Hope this gets released soon 👍

@patspam
Copy link

patspam commented Sep 12, 2020

Any ETA on this?

@jsg2021
Copy link
Contributor

jsg2021 commented Sep 12, 2020

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
Copy link

luluhoc commented Oct 13, 2020

Can you please update the parser?

@jsg2021
Copy link
Contributor

jsg2021 commented Oct 13, 2020

@luluhoc there is a PR waiting to merge.

@hroland
Copy link

hroland commented Dec 7, 2020

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

@twelve17
Copy link

twelve17 commented May 1, 2021

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

@canonic-epicure
Copy link

More over, EcmaModules support is available in Node 12 already

@chrisspiegl
Copy link

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.

kou pushed a commit to apache/arrow that referenced this issue May 16, 2021
Optional chaining makes the code more concise and easier to reason about.

Needs a fork of esm because of standard-things/esm#866.

Closes #10278 from domoritz/modern-js

Lead-authored-by: Dominik Moritz <domoritz@gmail.com>
Co-authored-by: p42-ai[bot] <72252241+p42-ai[bot]@users.noreply.github.com>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
@smcenlly
Copy link

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

@jdalton
Copy link
Member

jdalton commented May 21, 2021

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

michalursa pushed a commit to michalursa/arrow that referenced this issue Jun 13, 2021
Optional chaining makes the code more concise and easier to reason about.

Needs a fork of esm because of standard-things/esm#866.

Closes apache#10278 from domoritz/modern-js

Lead-authored-by: Dominik Moritz <domoritz@gmail.com>
Co-authored-by: p42-ai[bot] <72252241+p42-ai[bot]@users.noreply.github.com>
Signed-off-by: Sutou Kouhei <kou@clear-code.com>
mtsknn added a commit to koodikrapula/koodikrapula.fi that referenced this issue Jun 24, 2021
mtsknn added a commit to koodikrapula/koodikrapula.fi that referenced this issue Jun 26, 2021
ampcpmgp added a commit to ampcpmgp/vite-svelte-mocktimes-starter that referenced this issue Jun 26, 2021
esm not optional chaining support, workaround
standard-things/esm#866 (comment)
@alcalawil
Copy link

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
Copy link

cezarcarvalhaes commented Oct 27, 2021

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
Copy link

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

@chrisspiegl
Copy link

@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
Copy link

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

@flopail
Copy link

flopail commented Aug 18, 2023

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
Copy link

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

@Nantris
Copy link

Nantris commented Sep 6, 2023

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
Copy link

CleyFaye commented Sep 6, 2023

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
Copy link

Nantris commented Sep 6, 2023

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
Copy link

CleyFaye commented Sep 6, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests