feat: add esbuild support for .gql and .graphql files

[Saeris]

Adds https://github.com/luckycatfactory/esbuild-graphql-loader to the esbuild plugins list to enable loading of .gql and .graphql files.

As suggested in the plugin's docs, @graphql-tools/optimize is used to further reduce the output bundle size.

This change is required to support graphql server functions that use a SDL-first approach for defining their schemas (as opposed to Code-first).

Because esbuild does not support user configuration files, nor does zip-it-and-ship-it or netlify-cli provide a way for users to customize the esbuild configuration, the only option to support additional file types like this is through submitting a PR which adds support for it.

The only other alternative is to use the old method of using webpack to bundle functions.

[Saeris]

I'm not sure why tests are failing. I've added all of 6 lines practically lifted straight out of the plugin's documentation. A number of tests fail with graphqlLoaderPlugin is not a function which doesn't make sense, as you can go to definition on the import and see that it is in fact a function.

Could use some help here. Is it possible I'm running into this error because this library is using a forked version of esbuild? That's the only reason I can think of for why an off the shelf plugin wouldn't work as expected.

[eduardoboucas]

Hi @Saeris! Thanks for this PR.

Because esbuild does not support user configuration files, nor does zip-it-and-ship-it or netlify-cli provide a way for users to customize the esbuild configuration, the only option to support additional file types like this is through submitting a PR which adds support for it.

What configuration parameters would you like access to in order to achieve this without adding a plugin?

We're trying to take small steps with our esbuild integration and we're being very conservative with any plugins we add, since they have the potential to introduce complexity, points of failure and performance bottlenecks.

Before merging this, I'd like to understand what our options are and discuss possible alternatives that strike a good balance between providing flexibility and keeping zip-it-and-ship-it as lean as possible.

I'd love to hear your thoughts. Thanks!

[Saeris]

In this case I don't see an alternative to adding a plugin.

In a Babel/Webpack compiling/bundling environment you would need to do roughly the same thing, as there is no native way in the language to import .gql or .graphql files. Plugins are the recommended way to add loaders for additional file types such as this. The closest comparison in the esbuild docs is loading/compiling .svelte files: https://esbuild.github.io/plugins/#svelte-plugin

I understand that there are complexity and performance implications here. What I would prefer, and I wish esbuild supported this, was for users to be able to define their own configuration, enabling them to make the tradeoffs for themselves. If esbuild is how Netlify wants to go forward with bundling/compiling lambda functions then I think you're going to run into this problem often or you'll end up limiting what can be done with lambdas.

At the end of the day, all I'm trying to do is publish a GraphQL API to Netlify Functions and I'm trying not to run into the size limit. I thought maybe I'd have better results with esbuild than I am with babel + webpack.

[eduardoboucas]

If esbuild is how Netlify wants to go forward with bundling/compiling lambda functions then I think you're going to run into this problem often or you'll end up limiting what can be done with lambdas.

I agree with this, and I think it would be unwise not to take advantage of esbuild's plugin capabilities and the use cases that can be unlocked with community-driven plugins. But this adds to my concern about adding plugins to zip-it-and-ship-it's core, because it's not scalable for us to be adding a plugin for each possible use case and run all of them for everyone on every build.

I'm wondering whether we could define a very lightweight API that allowed people to add their own plugins, for example by looking for a esbuild-plugins directory and loading each file as a plugin. This way we could allow people to customise their own bundling pipeline to a level that wouldn't be possible in a centralised way, all without impacting the performance of the core service.

How do you feel about this direction?

[Saeris]

I'm wondering whether we could define a very lightweight API that allowed people to add their own plugins, for example by looking for a esbuild-plugins directory and loading each file as a plugin. This way we could allow people to customise their own bundling pipeline to a level that wouldn't be possible in a centralised way, all without impacting the performance of the core service.

Probably better to go with a configuration file written in JS, because with a directory you will have problems with arbitrary file types and if plugin ordering is important then a directory glob is not a good DX for handling that aspect either.

I can see this growing into an unofficial esbuild configuration file. So that's a decision you'll have to make as far as support goes. Perhaps take a look at preact-cli to see how they expose webpack in their configs, allowing user customization that way. That might be better than trying to merge configs, as it could give the user the ability to customize the defaults as well.

You would also want to use a config file format so that you can leverage type definitions. Though Typescript support is it's own topic.