Browse files

cleaned up repo

  • Loading branch information...
James Baxley
James Baxley committed Oct 28, 2017
1 parent 9f95818 commit 9845c990a58460db007a4264a54aa73859cc644a
Showing with 417 additions and 28 deletions.
  1. +25 −0 .travis.yml
  2. +82 −0
  3. +21 −0 LICENSE
  4. +23 −0 appveyor.yml
  5. +10 −0 codecov.yml
  6. +124 −0 dangerfile.ts
  7. +39 −11 package.json
  8. +13 −0 renovate.json
  9. +2 −2 src/__tests__/client.ts
  10. +4 −4 src/__tests__/index.ts
  11. +6 −6 src/index.ts
  12. +3 −5 src/utils.ts
  13. +65 −0 tslint.json
@@ -0,0 +1,25 @@
language: node_js
- "8"

- npm run bootstrap
- npm prune

- npm run danger

# using jest --coverage also runs the tests so this will cut down CI time
- npm run coverage

# run coverage and file size checks
- npm run coverage:upload || true #ignore failures

# make sure files don't get too large
- npm run filesize

# Allow Travis tests to run in containers.
sudo: false

email: false
@@ -0,0 +1,82 @@
# Apollo Contributor Guide

Excited about Apollo and want to make it better? We’re excited too!

Apollo is a community of developers just like you, striving to create the best tools and libraries around GraphQL. We welcome anyone who wants to contribute or provide constructive feedback, no matter the age or level of experience. If you want to help but don't know where to start, let us know, and we'll find something for you.

Oh, and if you haven't already, sign up for the [Apollo Slack](

Here are some ways to contribute to the project, from easiest to most difficult:

* [Reporting bugs](#reporting-bugs)
* [Improving the documentation](#improving-the-documentation)
* [Responding to issues](#responding-to-issues)
* [Small bug fixes](#small-bug-fixes)
* [Suggesting features](#feature-requests)
* [Big pull requests](#big-prs)

## Issues

### Reporting bugs

If you encounter a bug, please file an issue on GitHub via the repository of the sub-project you think contains the bug. If an issue you have is already reported, please add additional information or add a 👍 reaction to indicate your agreement.

While we will try to be as helpful as we can on any issue reported, please include the following to maximize the chances of a quick fix:

1. **Intended outcome:** What you were trying to accomplish when the bug occurred, and as much code as possible related to the source of the problem.
2. **Actual outcome:** A description of what actually happened, including a screenshot or copy-paste of any related error messages, logs, or other output that might be related. Places to look for information include your browser console, server console, and network logs. Please avoid non-specific phrases like “didn’t work” or “broke”.
3. **How to reproduce the issue:** Instructions for how the issue can be reproduced by a maintainer or contributor. Be as specific as possible, and only mention what is necessary to reproduce the bug. If possible, build a reproduction with our [error template]( to isolate the exact circumstances in which the bug occurs. Avoid speculation over what the cause might be.

Creating a good reproduction really helps contributors investigate and resolve your issue quickly. In many cases, the act of creating a minimal reproduction illuminates that the source of the bug was somewhere outside the library in question, saving time and effort for everyone.

### Improving the documentation

Improving the documentation, examples, and other open source content can be the easiest way to contribute to the library. If you see a piece of content that can be better, open a PR with an improvement, no matter how small! If you would like to suggest a big change or major rewrite, we’d love to hear your ideas but please open an issue for discussion before writing the PR.

### Responding to issues

In addition to reporting issues, a great way to contribute to Apollo is to respond to other peoples' issues and try to identify the problem or help them work around it. If you’re interested in taking a more active role in this process, please go ahead and respond to issues. And don't forget to say "Hi" on Apollo Slack!

### Small bug fixes

For a small bug fix change (less than 20 lines of code changed), feel free to open a pull request. We’ll try to merge it as fast as possible and ideally publish a new release on the same day. The only requirement is, make sure you also add a test that verifies the bug you are trying to fix.

### Suggesting features

Most of the features in Apollo came from suggestions by you, the community! We welcome any ideas about how to make Apollo better for your use case. Unless there is overwhelming demand for a feature, it might not get implemented immediately, but please include as much information as possible that will help people have a discussion about your proposal:

1. **Use case:** What are you trying to accomplish, in specific terms? Often, there might already be a good way to do what you need and a new feature is unnecessary, but it’s hard to know without information about the specific use case.
2. **Could this be a plugin?** In many cases, a feature might be too niche to be included in the core of a library, and is better implemented as a companion package. If there isn’t a way to extend the library to do what you want, could we add additional plugin APIs? It’s important to make the case for why a feature should be part of the core functionality of the library.
3. **Is there a workaround?** Is this a more convenient way to do something that is already possible, or is there some blocker that makes a workaround unfeasible?

Feature requests will be labeled as such, and we encourage using GitHub issues as a place to discuss new features and possible implementation designs. Please refrain from submitting a pull request to implement a proposed feature until there is consensus that it should be included. This way, you can avoid putting in work that can’t be merged in.

Once there is a consensus on the need for a new feature, proceed as listed below under “Big PRs”.

## Big PRs

This includes:

- Big bug fixes
- New features

For significant changes to a repository, it’s important to settle on a design before starting on the implementation. This way, we can make sure that major improvements get the care and attention they deserve. Since big changes can be risky and might not always get merged, it’s good to reduce the amount of possible wasted effort by agreeing on an implementation design/plan first.

1. **Open an issue.** Open an issue about your bug or feature, as described above.
2. **Reach consensus.** Some contributors and community members should reach an agreement that this feature or bug is important, and that someone should work on implementing or fixing it.
3. **Agree on intended behavior.** On the issue, reach an agreement about the desired behavior. In the case of a bug fix, it should be clear what it means for the bug to be fixed, and in the case of a feature, it should be clear what it will be like for developers to use the new feature.
4. **Agree on implementation plan.** Write a plan for how this feature or bug fix should be implemented. What modules need to be added or rewritten? Should this be one pull request or multiple incremental improvements? Who is going to do each part?
5. **Submit PR.** In the case where multiple dependent patches need to be made to implement the change, only submit one at a time. Otherwise, the others might get stale while the first is reviewed and merged. Make sure to avoid “while we’re here” type changes - if something isn’t relevant to the improvement at hand, it should be in a separate PR; this especially includes code style changes of unrelated code.
6. **Review.** At least one core contributor should sign off on the change before it’s merged. Look at the “code review” section below to learn about factors are important in the code review. If you want to expedite the code being merged, try to review your own code first!
7. **Merge and release!**

### Code review guidelines

It’s important that every piece of code in Apollo packages is reviewed by at least one core contributor familiar with that codebase. Here are some things we look for:

1. **Required CI checks pass.** This is a prerequisite for the review, and it is the PR author's responsibility. As long as the tests don’t pass, the PR won't get reviewed.
2. **Simplicity.** Is this the simplest way to achieve the intended goal? If there are too many files, redundant functions, or complex lines of code, suggest a simpler way to do the same thing. In particular, avoid implementing an overly general solution when a simple, small, and pragmatic fix will do.
3. **Testing.** Do the tests ensure this code won’t break when other stuff changes around it? When it does break, will the tests added help us identify which part of the library has the problem? Did we cover an appropriate set of edge cases? Look at the test coverage report if there is one. Are all significant code paths in the new code exercised at least once?
4. **No unnecessary or unrelated changes.** PRs shouldn’t come with random formatting changes, especially in unrelated parts of the code. If there is some refactoring that needs to be done, it should be in a separate PR from a bug fix or feature, if possible.
5. **Code has appropriate comments.** Code should be commented, or written in a clear “self-documenting” way.
6. **Idiomatic use of the language.** In TypeScript, make sure the typings are specific and correct. In ES2015, make sure to use imports rather than require and const instead of var, etc. Ideally a linter enforces a lot of this, but use your common sense and follow the style of the surrounding code.
@@ -0,0 +1,21 @@
The MIT License (MIT)

Copyright (c) 2016 - 2017 Meteor Development Group, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

@@ -0,0 +1,23 @@
# Test against this version of Node.js
# node.js
- nodejs_version: "8"

# Install scripts. (runs after repo cloning)
# Get the latest stable version of Node.js or io.js
- ps: Install-Product node $env:nodejs_version
# remove unused modules from node_modules directory
- npm prune
# install modules
- npm run bootstrap

# Post-install test scripts.
# run tests
- npm test

# nothing to compile in this project
build: off
deploy: off
@@ -0,0 +1,10 @@
enable_partials: yes
target: "83%"
enabled: false
@@ -0,0 +1,124 @@
// Removed import
import { includes } from 'lodash';
import * as fs from 'fs';

// Setup
const pr =;
const commits = danger.github.commits;
const modified = danger.git.modified_files;
const bodyAndTitle = (pr.body + pr.title).toLowerCase();

// Custom modifiers for people submitting PRs to be able to say "skip this"
const trivialPR = bodyAndTitle.includes('trivial');
const acceptedNoTests = bodyAndTitle.includes('skip new tests');

const typescriptOnly = (file: string) => includes(file, '.ts');
const filesOnly = (file: string) =>
fs.existsSync(file) && fs.lstatSync(file).isFile();

// Custom subsets of known files
const modifiedAppFiles = modified
.filter(p => includes(p, 'src') || includes(p, '__tests__'))
.filter(p => filesOnly(p) && typescriptOnly(p));

// Takes a list of file paths, and converts it into clickable links
const linkableFiles = paths => {
const repoURL =;
const ref =;
const links = => {
return createLink(`${repoURL}/blob/${ref}/${path}`, path);
return toSentence(links);

// ["1", "2", "3"] to "1, 2 and 3"
const toSentence = (array: Array<string>): string => {
if (array.length === 1) {
return array[0];
return array.slice(0, array.length - 1).join(', ') + ' and ' + array.pop();

// ("/href/thing", "name") to "<a href="/href/thing">name</a>"
const createLink = (href: string, text: string): string =>
`<a href='${href}'>${text}</a>`;

// Raise about missing code inside files
const raiseIssueAboutPaths = (
type: Function,
paths: string[],
codeToInclude: string,
) => {
if (paths.length > 0) {
const files = linkableFiles(paths);
const strict = '<code>' + codeToInclude + '</code>';
type(`Please ensure that ${strict} is enabled on: ${files}`);

const authors = =>;
const isBot = authors.some(x => ['greenkeeper', 'renovate'].indexOf(x) > -1);

// Rules
if (!isBot) {
// make sure someone else reviews these changes
// const someoneAssigned =;
// if (someoneAssigned === null) {
// warn(
// 'Please assign someone to merge this PR, and optionally include people who should review.'
// );
// }

// When there are app-changes and it's not a PR marked as trivial, expect
// there to be CHANGELOG changes.
// const changelogChanges = modified.some(x => x.indexOf('CHANGELOG') > -1);
// if (modifiedAppFiles.length > 0 && !trivialPR && !changelogChanges) {
// fail('No CHANGELOG added.');
// }

// No PR is too small to warrant a paragraph or two of summary
if (pr.body.length === 0) {
fail('Please add a description to your PR.');

const hasAppChanges = modifiedAppFiles.length > 0;

const testChanges = modifiedAppFiles.filter(filepath =>
const hasTestChanges = testChanges.length > 0;

// Warn when there is a big PR
const bigPRThreshold = 500;
if ( + >
) {
warn(':exclamation: Big PR');

// Warn if there are library changes, but not tests
if (hasAppChanges && !hasTestChanges) {
"There are library changes, but not tests. That's OK as long as you're refactoring existing code",

// Be careful of leaving testing shortcuts in the codebase
const onlyTestFiles = testChanges.filter(x => {
const content = fs.readFileSync(x).toString();
return (
content.includes('it.only') ||
content.includes('describe.only') ||
content.includes('fdescribe') ||
raiseIssueAboutPaths(fail, onlyTestFiles, 'an `only` was left in the test');

// Politely ask for their name in the authors file
message('Please add your name and email to the AUTHORS file (optional)');
'If this was a change that affects the external API, please update the docs and post a link to the PR in the discussion',
@@ -17,31 +17,52 @@
"homepage": "",
"scripts": {
"build:browser": "browserify ./lib/bundle.umd.js -o=./lib/bundle.js --i apollo-link && npm run minify:browser",
"browserify ./lib/bundle.umd.js -o=./lib/bundle.js --i apollo-link --i apollo-utilities --i graphql-anywhere && npm run minify:browser",
"build": "tsc -p .",
"bundle": "rollup -c",
"clean": "rimraf lib/* && rimraf coverage/*",
"filesize": "npm run build && npm run build:browser",
"lint": "tslint --type-check -p tsconfig.json -c ../../tslint.json src/*.ts",
"minify:browser": "uglifyjs -c -m -o ./lib/bundle.min.js -- ./lib/bundle.js",
"filesize": "npm run build && npm run build:browser && bundlesize",
"prelint": "npm run lint-fix",
"prettier --trailing-comma all --single-quote --write \"src/**/*.{j,t}s*\"",
"lint": "tslint --type-check -p tsconfig.json -c tslint.json src/*.ts",
"lint-staged": "lint-staged",
"uglifyjs -c -m -o ./lib/bundle.min.js -- ./lib/bundle.js",
"postbuild": "npm run bundle",
"prebuild": "npm run clean",
"prepublishOnly": "npm run clean && npm run build",
"test": "jest",
"watch": "tsc -w -p ."
"bundlesize": [
"name": "apollo-link-state",
"path": "./lib/bundle.min.js",
"threshold": "1.2 Kb"
"peerDependencies": {
"apollo-link": "^1.0.0"
"devDependencies": {
"@types/graphql": "0.11.5",
"@types/jest": "21.1.5",
"apollo-cache-inmemory": "^1.0.0",
"apollo-client": "^2.0.1",
"apollo-link": "^1.0.0",
"browserify": "14.5.0",
"bundlesize": "0.15.3",
"codecov": "3.0.0",
"danger": "1.2.0",
"graphql": "0.11.7",
"graphql-tag": "2.5.0",
"jest": "21.2.1",
"lerna": "2.4.0",
"lint-staged": "4.3.0",
"pre-commit": "1.2.2",
"prettier": "1.7.4",
"rimraf": "2.6.1",
"rollup": "0.45.2",
"ts-jest": "21.1.4",
@@ -54,15 +75,22 @@
".(ts|tsx)": "<rootDir>/node_modules/ts-jest/preprocessor.js"
"testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx|js)$",
"moduleFileExtensions": [
"moduleFileExtensions": ["ts", "tsx", "js", "json"]
"dependencies": {
"apollo-utilities": "^1.0.1",
"graphql-anywhere": "^4.0.0"
"lint-staged": {
"*.ts*": [
"prettier --trailing-comma all --single-quote --write",
"git add"
"*.js*": [
"prettier --trailing-comma all --single-quote --write",
"git add"
"*.json*": ["prettier --write", "git add"]
"pre-commit": "lint-staged"
@@ -0,0 +1,13 @@
"pinVersions": true,
"semanticCommits": true,
"depTypes": [{ "depType": "dependencies", "pinVersions": false }],
"timezone": "America/Los_Angeles",
"schedule": ["after 10pm and before 5am on every weekday"],
"rebaseStalePrs": true,
"prCreation": "not-pending",
"automerge": "minor",
"labels": ["tooling", "dependencies"],
"assignees": ["@jbaxleyiii"],
"reviewers": ["@jbaxleyiii"]
Oops, something went wrong.

0 comments on commit 9845c99

Please sign in to comment.