Reduce Bundle Size

[eduarddotgg]

Vue Apollo is a great tool. But it's size is huge. Is there any way to reduce it's size?

My proposal is to split plugin into few smaller piece. I would say Vue-Apollo has core features and some additional. Core features when you use vue-apollo inside custom components and I believe is the most common use case. Additional - vue-apollo components. The problem is that not everybody would like to use vue-apollo components. I think It would be a good idea to make them optional rather than always keep them inside the bundle.

This can make vue-apollo twice smaller.

[Austio]

I'd be happy to help with this refactor

[Austio]

@iamfrntdv do you have a size comparrison of with vs without the components?

[eduarddotgg]

Current build size:
vue-apollo.esm.js - 133kb
vue-apollo.min.js - 53kb
vue-apollo.umd.js - 142kb

Build without components:
vue-apollo.esm.js - 48kb
vue-apollo.min.js - 22kb
vue-apollo.umd.js - 51kb

As you can see it's a huge difference.

[rchl]

I've looked at vue-apollo.esm.js which is used by Nuxt.

I've noticed that large part of the code is the inlined graphql parser from graphql package. This shouldn't be necessary as graphql-tag (and thus indirectly graphql) is a peer dependency so it should be fine to just leave import gql from 'graphql-tag' as is.

I've achieved non-inlining with this change:

--- a/build/rollup.config.base.js
+++ b/build/rollup.config.base.js
@@ -15,6 +15,7 @@ export default {
     }),
     cjs({
       exclude: 'src/**',
+      ignore: ['graphql/language/parser'],
     }),
     babel({
       exclude: 'node_modules/**',

but there might be better way to do it. It makes the parser not be inlined but it still inlines graphql-tag.

A lot of bytes are saved with this change. Of course graphql-tag is still needed but at least won't be duplicated if your app include it in different place.

[rchl]

Both graphql-tag and graphql provide code in ES modules variant so it should be possible to just import but I haven't managed to do that in a short testing. I wonder if it's due to quite outdated rollup and rollup plugins dependencies. It would be worth to update those before experimenting more.