Parsing Error when using Nullish Assignment (??=)

[stephen-j-oleary]

I'm getting the following error when attempting to bundle my project.
Error: Parsing file /path/to/file.js: Unexpected token (13:22)
I've traced the error to a Nullish Assignment (??=) . Changing that line to a regular assignment allows the project to build without any errors.

Is there any way to add support for this type of assignment operator or should I just avoid using it?

Thanks

[ljharb]

What version of node are you using? If it doesn't support it natively, it can't work without transpilation.

Either way, you probably want to be transpiling (with babel) so that you can target older envs.

[stephen-j-oleary]

Thanks for the response. I'm using node v16.13.2 for this project. As far as I know, node supports it starting in version 15 so I thought it should work. I'll look into using babel and in the mean time just avoid logical assignment.

[newhouse]

@ljharb

Thanks for your comment here!

Is this project still being maintained? I encountered this error and I'm seeing a lot of other issues that are very similar with a common theme: some syntaxes that are supported natively in modern versions of Node are causing parsing errors in browserify / module-deps / detective.

Just roughly speaking it seems like browserify is not keeping up with the syntax of the more recent Node versions, or does not take into account the "target" Node/browser capabilities when parsing things.

Is there any way to make something like this work today without transpilation to an unnecessarily old syntax?

Or is there a way to transpile the code just-in-time for browserify only to figure out the deps?

Thanks!

[ljharb]

@newhouse yes, it's still being maintained. I agree that it's not keeping up, but that's not the same thing. Transpilation is pretty universally necessary anyways, so I'd suggest using a babel browserify transform as a workaround, while modern syntax support is pending in all the various deps of browserify.

[newhouse]

@ljharb Thanks for the reply.

Yeah I mean in my case I was already transpiling to a target that matched the runtime Node version of my code, but now that I've bumped the runtime I've also bumped the target and this error just started happening.

Since I was already transpiling I just kept an older target for now so it was not a big deal, but:

• it should not be necessary
• eventually something that can't be transpiled will cause a problem that the workaround can't solve
• native optimizations will be lost
• users writing in a syntax thats 100% supported by their runtime will find it more than annoying to have to use babel unnecessarily

Anyways, I appreciate this library, its complexity, your response, and the likely fact that all the things I just said you probably already knew. I just wanted to enumerate them a bit to have them out there.

I'm not even using this library directly - another dependency is - but is there a way to somehow for a User transform the code in just the offending spot in order get the desired results while not actually having the resulting code have been transpiled as well? Probably not but just wondering. And again I'm sorry I'm not actually super familiar with this library and am not directly consuming it.

[ljharb]

I suppose you could, yeah - you could probably run babel on a browserify bundle with the only enabled transforms being for the syntaxes you want to target? Seems awkward though.