Unexpected token: keyword (function) UglifyJs

[lyquocnam]

hi author, i trying to use rxdb with vuejs + cordova ( quasar framework )
but when build this bug happend.

ERROR in js/0.bcc8ac658f5ce5687243.js from UglifyJs
Unexpected token: keyword (function) [js/0.bcc8ac658f5ce5687243.js:590,6]

more detail i posted here: quasarframework/quasar#573
this error make app can not run on mobile cordova, please help !

[pubkey]

Hi @lyquocnam
To debug this, we need to know what code is in js/0.bcc8ac658f5ce5687243.js:590,6
Can you access this file? One option would be to disable UglifyJS to produce it.

[varbrad]

Hi @lyquocnam.
This error is produced by UglifyJS whenever it tries to 'uglify' a function that has been designated as an asynchronous function.

Depending on how the webpack setup is defined for the quasar-cli, you will need to run this bundle through a transpiler such as babel first. It looks like that function is being required in wholesale from rxjs somewhere.

NOTE: Offending function in your prod bundle;

async function assertThrowsAsync(test, error = Error, contains = '') { ... }

[lyquocnam]

my project here https://github.com/lyquocnam/quasar-test

[rstoenescu]

Hi all,

Didn't quite look, but is there a transpiled version of Rxdb in the npm package? This would solve the problem for all projects using Webpack by default, without the need to add Webpack exceptions, which is what most devs expect.

[varbrad]

Just a note that the naughty async function that is getting put into the pre-uglify file is being pulled in from rxdb/src/util.js, line 81. (That's what webpack is telling me anyway, webpack surely should never even be looking at this file?)

Looks like somewhere (rxdb?, webpack?) is pulling in the util async functions from the 'src' directory as opposed to the 'dist' transpiled asyncToGenerators?

[varbrad]

Ok I think I have figured it out. Webpack is using the module source from rxdb when being built. This results in webpack just using the source files rather than the dist files.

This means the async/await stuff just gets put into the resulting bundle, and then uglify-js gets confused when it sees them when attempting to uglify the source.

Also, if babel (or similar) is running within the quasar build step, then it will be ignoring node_modules (presumably, I haven't checked) and voila, there's the issue.

[rstoenescu]

@varbrad Hi, Please read this post from Rich Harris explaining what "jsnext:main" is and how it should be used by package owners, and then the next comment. Seems like rxdb has chosen option 3, but this complicates things a lot for devs using Webpack which have to do extra configuration. You might want to chose another option so that this will work "out of the box" with Webpack too. Most users just drop a package and search for replacement when having such problems -- not to mention not everyone is a Webpack wizard :) Just my opinion.

EDIT: forgot to add link :) reduxjs/redux#1042 (comment)

[varbrad]

Hi @rstoenescu, I am not the author of rxdb, that would be @pubkey. 👍
Also, unless I am being really dumb (it is very possible), I am not seeing the link you mention?
😃

[rstoenescu]

@varbrad Ah, you are right. Forgot to add the link itself :) Edited the post.

[pubkey]

Thank you @varbrad and @rstoenescu for the investigation.

It looks like RxDB is doing something wrong here.
Currently jsnext:main and module point to the es7-stage-0 code which seems to be the wrong way to go.
As seen on redux, we should transpile the es7 to es6 and let the jsnext:main point to the es6-version.

Would this fix the issue or do you see any further problems with this?

[varbrad]

I think that is the way to go, by exporting a CommonJS/UMD format for the main distributable version (as rxdb does correctly), and then export an ES module as jsnext:main/module using something like Babel.

[pubkey]

The commit d3a14cc417b04e32e2c534908dc62b0bcd654a5f handles this.
It would be nice if someone could countercheck this by pulling and run npm run build to verify the build-output.