feat(schema): Added support for schema imports

[kbrandwijk]

As discussed in #12. This happens as a pre-build step, so no downstream tooling is affected by it.
This does affect the replacement function in the upcoming install.js, but as that isn't merged yet, I can't update it. If this PR makes it first, the other one can be updated accordingly.

It probably needs a better sample (or no sample at all) in the boilerplate. The second schema added here is just to prove that it works, but I think it shouldn't be in the default boilerplate.

[jlengstorf]

Unfortunately, the CLI builds from source, so it falls down when we try to run it:

$ yarn dev
yarn run v1.3.2
$ gramps dev --data-source .

The GrAMPS CLI is intended for local development only.

 -> created a temporary directory at /Users/jasonlengstorf/dev/gramps-graphql/data-source-base/node_modules/@gramps/cli/.tmp/data-source-base
(node:7523) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): Error: /Users/jasonlengstorf/dev/gramps-graphql/data-source-base/src/index.js: Path './schema.bundled.graphql' could not be found for '/Users/jasonlengstorf/dev/gramps-graphql/data-source-base/src/index.js'
(node:7523) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
 -> cleaning up temporary files

Successfully shut down. Thanks for using GrAMPS!

error Command failed with signal "SIGTERM".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

However, this does run if we perform the following steps:

yarn build
yarn dev

It's easy enough to add a predev step for local data source development, but when working on a custom gateway, this could trip people up. 😕

# how will they know to build `data-source-mydata` before running this?
gramps dev -g ./my-gateway.js -d ../data-source-mydata

[kbrandwijk]

Wouldn't it be possible for the gramps cli to build a datasource first, before consuming it? And then use the file from ./dist/*.js instead of ./src/*.js? So you also don't need to do a babel transpile in code.

This is going to trip up anyway as soon as someone starts to develop a datasource in TS, and wants to use it locally. Then it should also run build on the datasource, and use the files from dist.
Depending on being able to run babel on a source folder in your cli is really, really brittle.
What if someone wants to build one in Reason? He would have no problem if he sets up his datasource package to run bsb on build. And the CLI would have no problem just using the files from the dist folder.
Or, what if someone uses other dependencies in their datasource? Babel wouldn't be able to resolve those, because it doesn't look at the package.json in the datasource folder.

[jlengstorf]

Yeah, adding a call to the build script is probably a more sustainable solution. I added transpilation because at IBM I have more control over what the data sources are built with.

I've opened a new issue to track the change: #16

[kbrandwijk]

One of the challenges of open-sourcing an internal lib 😄.