Webpack babel/polyfill breaks the Meteor Server runtime (check(..)) [workaround included] about meteor-webpack-react

[grigio]

I think webpack breaks in some way the Meteor runtime, the code below works in any classic Meteor app

./met shell or $ meteor shell
> var whatever = new Mongo.Collection("whatever")
> whatever.find().fetch()
[]
> whatever.find({},{limit:5}).fetch()
Error: Match error: Failed Match.OneOf or Match.Optional validation
    at checkSubtree (packages/check/match.js:244:1)
    at check (packages/check/match.js:32:1)
    at [object Object]._.extend._getFindOptions (packages/mongo/collection.js:239:1)
    at [object Object]._.extend.find (packages/mongo/collection.js:275:1)
    at repl:1:11

[grigio]

related to Meteor Babel #5 , it's a conflict with core meteor package "check"

check(5, Number)
Error: Match error: Expected Number
    at checkSubtree (packages/check/match.js:252:1)
    at check (packages/check/match.js:32:1)
    at repl:1:2

a workaround is:

check(5, Number(5))

But it is used in many situations

[jedwards1211]

Aha, "good to know" as you said :) Okay, this has me pissed at Meteor; why do they think they need to check that the programmer gave you a Number for the limit? There's no good reason! People need to relax and let duck typing do its work,. If the programmer says {limit: "5"} it's still perfectly valid to interpret that as 5. If the user says {limit: true} it would end up limiting to 1, but who cares?? They could just explain in the docs that whatever the programmer provides will be converted to a number according to usual JS rules.

[jedwards1211]

{limit: Number(5)} doesn't seem to be working for me unfortunately. I'll have to look at how to incorporate the custom build you did...

[grigio]

I confirm Number(5) hack doesn't work with mongo collections, unfortunatly check(..) is used everywhere in Meteor,.. limit, subscriptions,.. also on parameters hardcoded server-side XD

[AdamBrodzinski]

Hmm how do they get around this using the core babel and core-js? Must be using a custom build?

[grigio]

The workaround that worked for grigio:babel is to embed core-js built without ES2015 Number support

[grigio]

in webpack.config.server.js with

...
module.exports = {
  entry: [
    // 'babel/polyfill', //disabled
    '../app/main_server',
  ],
...

It seems it is fixed, probably we should load here a polyfill without ES2015 Numbers

[grigio]

I confirm. Disabling 'babel/polyfill' in webpack server fix this particular issue

[AdamBrodzinski]

Thanks for getting to the bottom of this @grigio I'm sure I would have been cursing and banging my head against the wall on this one lol.

[grigio]

I did it :D, I've also tried your example on the Meteor forum but the problem wasn't my code... this is what I meant with side-effects.

@jedwards1211 what do you think is better to do? Disable 'babel/polyfill' on the server or embed a custom polyfill with corejs without ES2015 Number?

[jedwards1211]

I'd definitely rather embed a custom polyfill, as the goal of this project was to enable as many ES6 features as possible. Sorry, I've been busy lately, I can try to work on this later but if you have any idea yet how to work the custom build into this project feel free to make a PR.

[grigio]

Some feature provided by the polyfill may be dangerous numtel/pg-live-select#3

[jedwards1211]

Ah man...I guess I'm not too surprised, given how new all these tools are. Thanks for the heads up on that. It's a bummer...I was hoping to start trying out async/await soon.

[AdamBrodzinski]

Yea async/await is really nice... I've been using it on react native lately. They're adding async-await support in the future by converting over to promise based methods. They have a really nice promise polyfill for the server too....actually not quite sure if we can make that work with babel now....I'm sure something would go wrong lol.

[AdamBrodzinski]

Same issue when running the velocity. Commenting out the polyfills works though.

Testing with velocity and jasmine works well so far. You can either put tests in:
meteor_core/tests/jasmine/client/integration/greeting_spec.js
or a more flat path with symlinks
tests/acceptance_client/greeting_spec.js

I don't see any way to symlink them into meteor_core if they're next to the source files in app 😞 The unit tests with the Karma runner allow that though!

At any rate i'll wait until this issue is resolved before pulling these in since they'll break the build step.

[jedwards1211]

Okay guys, I just pushed a script that custom builds core-js, and now it uses that and regenerator/runtime instead of babel/polyfill in the webpack entry points. Try it out! Thanks Luigi for pointing me to your solution, otherwise I may never have figured this out!

[AdamBrodzinski]

Awesome! I'll try to push the test stuff on my flight back on Thurs.... will have major down time then lol.

It's a bummer...I was hoping to start trying out async/await soon.

BTW, I just lost some hair using these and not realizing that in current V8 builds any async function will swallow all exceptions (like undefined vars lol) if it doesn't have a try/catch around the caller. I guess this will be resolved in the future.

[jedwards1211]

Oh wow. Good to know!

[jedwards1211]

And @AdamBrodzinski I don't know if you read much through Luigi's link but basically one guy who was using async/await had memory leaks that were solved once he stopped using them :(

[AdamBrodzinski]

Yikes.... they're turned on by default in RN in 0.10.0-rc so maybe the latest babel fixes that? I'll have to keep an eye on memory 👍

[jedwards1211]

I'm going to close this. I just fixed an issue where the new custom build script wasn't getting the core js version correctly. If any more issues come up with the babel polyfill replacement, feel free to open a new issue.