Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use UMD bundle and ES6 modules #1069

Merged
merged 18 commits into from
Jan 5, 2017
Merged

Use UMD bundle and ES6 modules #1069

merged 18 commits into from
Jan 5, 2017

Conversation

kamilkisiela
Copy link
Contributor

@kamilkisiela kamilkisiela commented Dec 20, 2016

UMD bundle for everyone and a version with ES6 modules for those who might be interested in tree-shaking etc.

@helfer We talked some time ago about the tree-shaking. I already moved angular2-apollo (released), apollo-client-rxjs (not yet published) and created an example (will publish it later today).

TODO:

  • If this PR is a new feature, reference an issue where a consensus about the design was reached (not necessary for small changes)
  • Make sure all of the significant new logic is covered by tests
  • Rebase your changes on master so that they can be merged easily
  • Make sure all tests and linter rules pass
  • Update CHANGELOG.md with your change
  • Add your name and email to the AUTHORS file (optional)
  • If this was a change that affects the external API, update the docs and post a link to the PR in the discussion

Rollup

We use rollup to produce the UMD bundle that contains all files. This way we get smaller size of the library and support for CommonJS and AMD.

ESM (ES6 Modules)

We compile TS files to ES5, so this stays the same. Only difference is that we use es6 modules instead of commonjs. Thanks to that change the apollo-client is tree-shaking friendly

main and module

To make these changes to work with most of build tools we use main and module fields of package.json:

{
  "main": "apollo.umd.js",
  "module": "index.js"
}

module tells where to look for ES6 modules.
main the same as before, points to files with CommonJS (in this case, only one file)

Filesize

Because we use rollup and we have everything inside just one file, size of the library has been reduced.

Before:
The total size of index.min.js is 136 kB.
The total gzipped size of index.min.js is 35.7 kB.

After:
The total size of index.min.js is 127 kB.
The total gzipped size of index.min.js is 34.8 kB.

Tests

You probably noticed that I use babel to compile already compiled files.

When TypeScript sees this:

import isBoolean from 'lodash/isBoolean';
console.log(isBoolean(false));

It's being compiled to:

var isBoolean = require('lodash/isBoolean');
console.log(isBoolean(false).default);

And since lodash/isBoolean looks like this:

var isBoolean = require('../index').isBoolean;
module.exports = isBoolean;

We end up with isBoolean as undefined.

This is why I use babel to compile ES5 file with ES6 modules to CommonJS so mocha could handle it.

Deploy

I also applied these changes in scripts/deploy.sh.

Circular Dependencies

We also fixed the issue #1074


After this PR we can merge these:

PS @Urigo I wrote a summary so everyone can easily follow changes etc

@helfer
Copy link
Contributor

helfer commented Dec 21, 2016

@kamilkisiela is this PR intended for reference only?

@kamilkisiela
Copy link
Contributor Author

@helfer I was working on an example for angular2-apollo that has the tree-shaking and the Ahead-of-Time compilation and it would be nice to have es6 modules in apollo-client to make the app even smaller and tree-shake friendly.

So I ended up with these changes and I decided to open a PR and a discussion :)

@helfer
Copy link
Contributor

helfer commented Dec 23, 2016

@kamilkisiela @Urigo this is a pretty major change, so it would have been very useful if you let me know beforehand so we could plan things and avoid wasting time by having to redo parts of this PR (or other PRs) after merging other stuff. It's also unfortunate that removing circular dependencies was rolled in with this PR, I think we could have merged it more quickly otherwise (no need to manually check that the Apollo Client package doesn't break).

Other than that, I think this is pretty cool, so thanks for the hard work! It looks like tree-shaking doesn't actually do much for our library size, but it's always nice to support it.

"typings": "./lib/src/index.d.ts",
"scripts": {
"dev": "./scripts/dev.sh",
"deploy": "rm -rf ./lib && npm run compile && ./scripts/deploy.sh",
"pretest": "npm run compile",
"deploy": "rm -rf ./lib && ./scripts/deploy.sh",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the assumption here that the compiler and bundler already ran at this point?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

npm run compile is here, so there's no point of running it twice

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

@DxCx
Copy link
Contributor

DxCx commented Dec 23, 2016

Nicely done!
@helfer, please note that the library size kept about the same as not what you should look at.
With the patch apollo client will be treeshake ready, so clients that needs to use only part of the library will get much smaller bundle sizes..

@helfer
Copy link
Contributor

helfer commented Dec 25, 2016

@DxCx yeah, I understand that. At the same time it's surprising to see that tree shaking doesn't reduce the library size because I assumed that we had a lot of dependencies of which we only use a small part. I guess that means we were pretty good at only importing what we really needed.

@helfer
Copy link
Contributor

helfer commented Dec 25, 2016

@kamilkisiela Can I bug you again when I think things are stable enough to merge this into the 0.6 branch? A lot of conflicts will need to be resolved, so I think it would make sense to do this in a relatively short timeframe once we're ready.

@kamilkisiela
Copy link
Contributor Author

@helfer Sure thing! 👍

@helfer
Copy link
Contributor

helfer commented Jan 4, 2017

@kamilkisiela do you have time to change the base of this PR to zero-decimal-six in the next day or two and fix all the conflicts? If you can, then I can merge it and release it with 0.6 :)

@kamilkisiela
Copy link
Contributor Author

kamilkisiela commented Jan 4, 2017

@helfer Yep. There's an issue with code coverage reports, I'm working on it.

@kamilkisiela
Copy link
Contributor Author

@helfer Maybe we could update the redux to at least ^3.4.0? This way we get the official typescript definitions so we can drop @types/redux

@kamilkisiela
Copy link
Contributor Author

Closes #746

kamilkisiela and others added 10 commits January 4, 2017 17:45
Note: Typescript files with only types, are used only in compilation
phase and not going to be imported on compiled javascript.

Closes #1074
This way we avoid an issue with require('lodash/someFunction').default()
@kamilkisiela
Copy link
Contributor Author

change the base of this PR to zero-decimal-six

@helfer Okay, done.

@helfer
Copy link
Contributor

helfer commented Jan 4, 2017

@kamilkisiela re updating redux: sure thing, feel free to update it to the latest (compatible) version!

@helfer
Copy link
Contributor

helfer commented Jan 4, 2017

Okay, done.

Hm, that's weird, it still says the base is master on github.

edit: Oh, I see, you rebased, but you didn't change the base...

@kamilkisiela kamilkisiela changed the base branch from master to zero-decimal-six January 4, 2017 16:54
@kamilkisiela
Copy link
Contributor Author

@helfer Yes... Look now

This way we avoid using @types/redux and we use official typescript definition instead
@helfer
Copy link
Contributor

helfer commented Jan 5, 2017

Thanks a lot @kamilkisiela, merging now!

@helfer helfer merged commit 08d6dfc into zero-decimal-six Jan 5, 2017
@helfer helfer removed the in progress label Jan 5, 2017
@helfer helfer deleted the umd branch January 5, 2017 04:05
@lucasconstantino
Copy link
Contributor

lucasconstantino commented Jan 24, 2017

I'm trying to upgrade from 0.5.10 to 0.8.0 (as a sugestion from #1194) but I'm experiencing an unexpected token error. As far as I could investigate, importing apollo-client as import Apollo from "apollo-client" and using Webpack to build my app is ending up with a export function somewhere in the bundled file.

Any thoughts? Posting here because it definitely seems related.

EDIT: Ok, I found the issue: I'm importing ApolloError class to do some custom error normalization. The problem is on version 0.5.10 I could simply import doing import { ApolloError } from 'apollo-client/errors/ApolloError' but now that only the apollo.umd.js is properly transpiled into ES5, that's the only file I can trust.

This error normalization is not the only low-level api I'm using from Apollo... I hope I can find them through the officially exported bundle.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants