async / await ... how to build with babel

[tomitrescak]

Hi, I'm trying to build an NPM package that would provide some helper functions for meteor users. The issue is thta no matter how I build it from ES6/7 code, the async await functions always complain about fibers and they do not work.

What is the babel config that would work?
Here is my .bablerc

{
  "presets": ["es2015", "stage-0"],
  "plugins": [
    ["transform-runtime", {
      "polyfill": false,
      "regenerator": true
    }]
  ]
}

[stubailo]

Where are you putting the async await functions? The npm package is pre-built before publishing to NPM, so it's not really a problem with this package.

BTW @lorensr was thinking of working on a Meteor integration package as well!

[tomitrescak]

For example in following code it says: "Can't wait without fiber" on line with Meteor.user retrieval

graphQLServer.use('/graphql', apolloServer(async(req) => {
    let user = null; 
    if (req.headers.authorization) {
      const token = req.headers.authorization;
      check(token, String);
      const hashedToken = Accounts._hashLoginToken(token);
      user = await Meteor.users.findOne({
        "services.resume.loginTokens.hashedToken": hashedToken
      });
    }

    return {
      graphiql: true,
      pretty: true,
      schema,
      resolvers,
      context: {
        // The current user will now be available on context.user in all resolvers
        user,
      }
    };
  }));

[stubailo]

It works fine here: https://github.com/apollostack/meteor-starter-kit/blob/master/server/main.js

I guess you put this code into an NPM package, and it doesn't work anymore?

The async fiber support relies on Meteor's Promise polyfill, so you should make sure you aren't including any other promise polyfills in your NPM package.

[tomitrescak]

The previous code works flawlessly in Meteor, but when built as Npm package it fails.

[tomitrescak]

Ha! The Meteor polyfill will be the problem ... would you be able to point me out how can I use it with babel?

[stubailo]

You could just not use async/await in your package btw - that would be the easiest choice. Also, I'd suggest using an Atmosphere package instead of NPM for the short term, until Meteor 1.5 makes it possible for NPM packages to take advantage of more Meteor features.

[tomitrescak]

I'll try with atmosphere package. Good idea.

I cannot work without async/await as all update / insert queries fail complaining that they do not run in Meteor Fiber.

[lorensr]

@tomitrescak Hi Tomas, here's the shell I made for the atmosphere package:

https://github.com/apollostack/meteor-integration

I'd be interested to hear your thoughts on the API:

apollographql/meteor-integration#2

And would be happy to work on PRs with you if you'd like to combine efforts 😄

[tomitrescak]

@lorensr looks great! I'll give it a go. My effort is not going very well. Just created the meteor package but am still getting "Meteor code must always run within a Fiber. Try wrapping callbacks that you pass to non-Meteor libraries with Meteor.bindEnvironment." error.

Wht I miss in the package is the possibility to incrementally add resolvers. In a complex application with 50+ queries it would be great to have a possibility to split queries and mutations by modules. That is one of the things I tried to implement, but am hitting the wall with async.

I tried to look at how you've done it, but looks like you currently have only a shell, no implementation.

So, when you start to implement "useMeteorAccounts" you probably will run into very same issue. There the error is "Cannot await when not in Fiber".

[tomitrescak]

Also, would be great if you would hide all NPM packages into the Meteor package so no Npm install would be necessary.

My repo is here:

https://github.com/tomitrescak/apollo-redux-tools.git

[stubailo]

Also, would be great if you would hide all NPM packages into the Meteor package so no Npm install would be necessary.

Definitely DO NOT do this. The whole idea is that you can update the NPM package as necessary without waiting for the Meteor package maintainer to get around to updating their wrapper.

[stubailo]

Wht I miss in the package is the possibility to incrementally add resolvers.

You can use _.merge to combine as many resolver objects as you want.

[tomitrescak]

@stubailo ... just bumped into Meteor recommendation to NOT do that ;)

[stubailo]

What do you mean?

[tomitrescak]

I confirmed what you just said. I was checking the Meteor recommendations for package authors.

[tomitrescak]

The moment I moved all npm dependencies form package to root level the async problem disappeared, yet another one appeared as "context" is always null in my queries.

This is how I init the server:

const res = {
      graphiql: true,
      pretty: true,
      schema,
      resolvers,
      context: {
        // The current user will now be available on context.user in all resolvers
        user,
      }
    };

I'm sure that user is filled in. Then in my mutation:

addComment(root: any, { postId, comment }: any, context: any) {
    console.log("adding: " + context);
    const id = Comments.insert({ postId: postId, text: comment, createdAt: new Date().getTime(), author: context.user._id });
    return Posts.findOne(id);
  }

The context is null. Do you have any idea why this could happen?

[EDIT] Nevermind ... all solved.

[tomitrescak]

@lorensr I like the API, most of it is there. I'll try to do the PR tomorrow with what I've done. You'll see how much of it is trash.