Skip to content

Commit fdb954e

Browse files
peggyrayzispeggyrayzis
committed
Set up all the build infra
1 parent 89423b2 commit fdb954e

12 files changed

+1651
-35
lines changed

‎.gitignore

+1-2
Original file line numberDiff line numberDiff line change
@@ -2,5 +2,4 @@
22
/node_modules
33
package-lock.json
44
yarn-error.log
5-
npm-debug.log
6-
dist/
5+
npm-debug.log

‎.npmignore

+9
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
lib/types/
2+
src/
3+
.travis.yml
4+
tsconfig.json
5+
dangerfile.ts
6+
appveyor.yml
7+
codecov.yml
8+
renovate.json
9+
rollup.config.js

‎.travis.yml

+21
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
language: node_js
2+
node_js:
3+
- "8"
4+
5+
script:
6+
- npm run danger
7+
8+
# using jest --coverage also runs the tests so this will cut down CI time
9+
- npm run coverage
10+
11+
# run coverage and file size checks
12+
- npm run coverage:upload || true #ignore failures
13+
14+
# make sure files don't get too large
15+
- npm run filesize
16+
17+
# Allow Travis tests to run in containers.
18+
sudo: false
19+
20+
notifications:
21+
email: false

‎CONTRIBUTING.md

+173
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,173 @@
1+
# Apollo Contributor Guide
2+
3+
Excited about Apollo and want to make it better? We’re excited too!
4+
5+
Apollo is a community of developers just like you, striving to create the best
6+
tools and libraries around GraphQL. We welcome anyone who wants to contribute or
7+
provide constructive feedback, no matter the age or level of experience. If you
8+
want to help but don't know where to start, let us know, and we'll find
9+
something for you.
10+
11+
Oh, and if you haven't already, sign up for the
12+
[Apollo Slack](http://www.apollodata.com/#slack).
13+
14+
Here are some ways to contribute to the project, from easiest to most difficult:
15+
16+
* [Reporting bugs](#reporting-bugs)
17+
* [Improving the documentation](#improving-the-documentation)
18+
* [Responding to issues](#responding-to-issues)
19+
* [Small bug fixes](#small-bug-fixes)
20+
* [Suggesting features](#feature-requests)
21+
* [Big pull requests](#big-prs)
22+
23+
## Issues
24+
25+
### Reporting bugs
26+
27+
If you encounter a bug, please file an issue on GitHub via the repository of the
28+
sub-project you think contains the bug. If an issue you have is already
29+
reported, please add additional information or add a 👍 reaction to indicate
30+
your agreement.
31+
32+
While we will try to be as helpful as we can on any issue reported, please
33+
include the following to maximize the chances of a quick fix:
34+
35+
1. **Intended outcome:** What you were trying to accomplish when the bug
36+
occurred, and as much code as possible related to the source of the problem.
37+
2. **Actual outcome:** A description of what actually happened, including a
38+
screenshot or copy-paste of any related error messages, logs, or other output
39+
that might be related. Places to look for information include your browser
40+
console, server console, and network logs. Please avoid non-specific phrases
41+
like “didn’t work” or “broke”.
42+
3. **How to reproduce the issue:** Instructions for how the issue can be
43+
reproduced by a maintainer or contributor. Be as specific as possible, and
44+
only mention what is necessary to reproduce the bug. If possible, build a
45+
reproduction with our
46+
[error template](https://github.com/apollographql/react-apollo-error-template)
47+
to isolate the exact circumstances in which the bug occurs. Avoid speculation
48+
over what the cause might be.
49+
50+
Creating a good reproduction really helps contributors investigate and resolve
51+
your issue quickly. In many cases, the act of creating a minimal reproduction
52+
illuminates that the source of the bug was somewhere outside the library in
53+
question, saving time and effort for everyone.
54+
55+
### Improving the documentation
56+
57+
Improving the documentation, examples, and other open source content can be the
58+
easiest way to contribute to the library. If you see a piece of content that can
59+
be better, open a PR with an improvement, no matter how small! If you would like
60+
to suggest a big change or major rewrite, we’d love to hear your ideas but
61+
please open an issue for discussion before writing the PR.
62+
63+
### Responding to issues
64+
65+
In addition to reporting issues, a great way to contribute to Apollo is to
66+
respond to other peoples' issues and try to identify the problem or help them
67+
work around it. If you’re interested in taking a more active role in this
68+
process, please go ahead and respond to issues. And don't forget to say "Hi" on
69+
Apollo Slack!
70+
71+
### Small bug fixes
72+
73+
For a small bug fix change (less than 20 lines of code changed), feel free to
74+
open a pull request. We’ll try to merge it as fast as possible and ideally
75+
publish a new release on the same day. The only requirement is, make sure you
76+
also add a test that verifies the bug you are trying to fix.
77+
78+
### Suggesting features
79+
80+
Most of the features in Apollo came from suggestions by you, the community! We
81+
welcome any ideas about how to make Apollo better for your use case. Unless
82+
there is overwhelming demand for a feature, it might not get implemented
83+
immediately, but please include as much information as possible that will help
84+
people have a discussion about your proposal:
85+
86+
1. **Use case:** What are you trying to accomplish, in specific terms? Often,
87+
there might already be a good way to do what you need and a new feature is
88+
unnecessary, but it’s hard to know without information about the specific use
89+
case.
90+
2. **Could this be a plugin?** In many cases, a feature might be too niche to be
91+
included in the core of a library, and is better implemented as a companion
92+
package. If there isn’t a way to extend the library to do what you want,
93+
could we add additional plugin APIs? It’s important to make the case for why
94+
a feature should be part of the core functionality of the library.
95+
3. **Is there a workaround?** Is this a more convenient way to do something that
96+
is already possible, or is there some blocker that makes a workaround
97+
unfeasible?
98+
99+
Feature requests will be labeled as such, and we encourage using GitHub issues
100+
as a place to discuss new features and possible implementation designs. Please
101+
refrain from submitting a pull request to implement a proposed feature until
102+
there is consensus that it should be included. This way, you can avoid putting
103+
in work that can’t be merged in.
104+
105+
Once there is a consensus on the need for a new feature, proceed as listed below
106+
under “Big PRs”.
107+
108+
## Big PRs
109+
110+
This includes:
111+
112+
* Big bug fixes
113+
* New features
114+
115+
For significant changes to a repository, it’s important to settle on a design
116+
before starting on the implementation. This way, we can make sure that major
117+
improvements get the care and attention they deserve. Since big changes can be
118+
risky and might not always get merged, it’s good to reduce the amount of
119+
possible wasted effort by agreeing on an implementation design/plan first.
120+
121+
1. **Open an issue.** Open an issue about your bug or feature, as described
122+
above.
123+
2. **Reach consensus.** Some contributors and community members should reach an
124+
agreement that this feature or bug is important, and that someone should work
125+
on implementing or fixing it.
126+
3. **Agree on intended behavior.** On the issue, reach an agreement about the
127+
desired behavior. In the case of a bug fix, it should be clear what it means
128+
for the bug to be fixed, and in the case of a feature, it should be clear
129+
what it will be like for developers to use the new feature.
130+
4. **Agree on implementation plan.** Write a plan for how this feature or bug
131+
fix should be implemented. What modules need to be added or rewritten? Should
132+
this be one pull request or multiple incremental improvements? Who is going
133+
to do each part?
134+
5. **Submit PR.** In the case where multiple dependent patches need to be made
135+
to implement the change, only submit one at a time. Otherwise, the others
136+
might get stale while the first is reviewed and merged. Make sure to avoid
137+
“while we’re here” type changes - if something isn’t relevant to the
138+
improvement at hand, it should be in a separate PR; this especially includes
139+
code style changes of unrelated code.
140+
6. **Review.** At least one core contributor should sign off on the change
141+
before it’s merged. Look at the “code review” section below to learn about
142+
factors are important in the code review. If you want to expedite the code
143+
being merged, try to review your own code first!
144+
7. **Merge and release!**
145+
146+
### Code review guidelines
147+
148+
It’s important that every piece of code in Apollo packages is reviewed by at
149+
least one core contributor familiar with that codebase. Here are some things we
150+
look for:
151+
152+
1. **Required CI checks pass.** This is a prerequisite for the review, and it is
153+
the PR author's responsibility. As long as the tests don’t pass, the PR won't
154+
get reviewed.
155+
2. **Simplicity.** Is this the simplest way to achieve the intended goal? If
156+
there are too many files, redundant functions, or complex lines of code,
157+
suggest a simpler way to do the same thing. In particular, avoid implementing
158+
an overly general solution when a simple, small, and pragmatic fix will do.
159+
3. **Testing.** Do the tests ensure this code won’t break when other stuff
160+
changes around it? When it does break, will the tests added help us identify
161+
which part of the library has the problem? Did we cover an appropriate set of
162+
edge cases? Look at the test coverage report if there is one. Are all
163+
significant code paths in the new code exercised at least once?
164+
4. **No unnecessary or unrelated changes.** PRs shouldn’t come with random
165+
formatting changes, especially in unrelated parts of the code. If there is
166+
some refactoring that needs to be done, it should be in a separate PR from a
167+
bug fix or feature, if possible.
168+
5. **Code has appropriate comments.** Code should be commented, or written in a
169+
clear “self-documenting” way.
170+
6. **Idiomatic use of the language.** In TypeScript, make sure the typings are
171+
specific and correct. In ES2015, make sure to use imports rather than require
172+
and const instead of var, etc. Ideally a linter enforces a lot of this, but
173+
use your common sense and follow the style of the surrounding code.

‎LICENSE

+21
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
The MIT License (MIT)
2+
3+
Copyright (c) 2016 - 2017 Meteor Development Group, Inc.
4+
5+
Permission is hereby granted, free of charge, to any person obtaining a copy
6+
of this software and associated documentation files (the "Software"), to deal
7+
in the Software without restriction, including without limitation the rights
8+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9+
copies of the Software, and to permit persons to whom the Software is
10+
furnished to do so, subject to the following conditions:
11+
12+
The above copyright notice and this permission notice shall be included in all
13+
copies or substantial portions of the Software.
14+
15+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21+
SOFTWARE.

‎appveyor.yml

+23
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
# Test against this version of Node.js
2+
environment:
3+
matrix:
4+
# node.js
5+
- nodejs_version: "8"
6+
7+
# Install scripts. (runs after repo cloning)
8+
install:
9+
# Get the latest stable version of Node.js or io.js
10+
- ps: Install-Product node $env:nodejs_version
11+
# remove unused modules from node_modules directory
12+
- npm prune
13+
# install modules
14+
- npm run bootstrap
15+
16+
# Post-install test scripts.
17+
test_script:
18+
# run tests
19+
- npm test
20+
21+
# nothing to compile in this project
22+
build: off
23+
deploy: off

‎codecov.yml

+10
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
coverage:
2+
parsers:
3+
javascript:
4+
enable_partials: yes
5+
status:
6+
project:
7+
default:
8+
target: "60%"
9+
patch:
10+
enabled: false

‎dangerfile.ts

+124
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,124 @@
1+
// Removed import
2+
import { includes } from 'lodash';
3+
import * as fs from 'fs';
4+
5+
// Setup
6+
const pr = danger.github.pr;
7+
const commits = danger.github.commits;
8+
const modified = danger.git.modified_files;
9+
const bodyAndTitle = (pr.body + pr.title).toLowerCase();
10+
11+
// Custom modifiers for people submitting PRs to be able to say "skip this"
12+
const trivialPR = bodyAndTitle.includes('trivial');
13+
const acceptedNoTests = bodyAndTitle.includes('skip new tests');
14+
15+
const typescriptOnly = (file: string) => includes(file, '.ts');
16+
const filesOnly = (file: string) =>
17+
fs.existsSync(file) && fs.lstatSync(file).isFile();
18+
19+
// Custom subsets of known files
20+
const modifiedAppFiles = modified
21+
.filter(p => includes(p, 'src') || includes(p, '__tests__'))
22+
.filter(p => filesOnly(p) && typescriptOnly(p));
23+
24+
// Takes a list of file paths, and converts it into clickable links
25+
const linkableFiles = paths => {
26+
const repoURL = danger.github.pr.head.repo.html_url;
27+
const ref = danger.github.pr.head.ref;
28+
const links = paths.map(path => {
29+
return createLink(`${repoURL}/blob/${ref}/${path}`, path);
30+
});
31+
return toSentence(links);
32+
};
33+
34+
// ["1", "2", "3"] to "1, 2 and 3"
35+
const toSentence = (array: Array<string>): string => {
36+
if (array.length === 1) {
37+
return array[0];
38+
}
39+
return array.slice(0, array.length - 1).join(', ') + ' and ' + array.pop();
40+
};
41+
42+
// ("/href/thing", "name") to "<a href="/href/thing">name</a>"
43+
const createLink = (href: string, text: string): string =>
44+
`<a href='${href}'>${text}</a>`;
45+
46+
// Raise about missing code inside files
47+
const raiseIssueAboutPaths = (
48+
type: Function,
49+
paths: string[],
50+
codeToInclude: string
51+
) => {
52+
if (paths.length > 0) {
53+
const files = linkableFiles(paths);
54+
const strict = '<code>' + codeToInclude + '</code>';
55+
type(`Please ensure that ${strict} is enabled on: ${files}`);
56+
}
57+
};
58+
59+
const authors = commits.map(x => x.author.login);
60+
const isBot = authors.some(x => ['greenkeeper', 'renovate'].indexOf(x) > -1);
61+
62+
// Rules
63+
if (!isBot) {
64+
// make sure someone else reviews these changes
65+
// const someoneAssigned = danger.github.pr.assignee;
66+
// if (someoneAssigned === null) {
67+
// warn(
68+
// 'Please assign someone to merge this PR, and optionally include people who should review.'
69+
// );
70+
// }
71+
72+
// When there are app-changes and it's not a PR marked as trivial, expect
73+
// there to be CHANGELOG changes.
74+
// const changelogChanges = modified.some(x => x.indexOf('CHANGELOG') > -1);
75+
// if (modifiedAppFiles.length > 0 && !trivialPR && !changelogChanges) {
76+
// fail('No CHANGELOG added.');
77+
// }
78+
79+
// No PR is too small to warrant a paragraph or two of summary
80+
if (pr.body.length === 0) {
81+
fail('Please add a description to your PR.');
82+
}
83+
84+
const hasAppChanges = modifiedAppFiles.length > 0;
85+
86+
const testChanges = modifiedAppFiles.filter(filepath =>
87+
filepath.includes('test')
88+
);
89+
const hasTestChanges = testChanges.length > 0;
90+
91+
// Warn when there is a big PR
92+
const bigPRThreshold = 500;
93+
if (
94+
danger.github.pr.additions + danger.github.pr.deletions >
95+
bigPRThreshold
96+
) {
97+
warn(':exclamation: Big PR');
98+
}
99+
100+
// Warn if there are library changes, but not tests
101+
if (hasAppChanges && !hasTestChanges) {
102+
warn(
103+
"There are library changes, but not tests. That's OK as long as you're refactoring existing code"
104+
);
105+
}
106+
107+
// Be careful of leaving testing shortcuts in the codebase
108+
const onlyTestFiles = testChanges.filter(x => {
109+
const content = fs.readFileSync(x).toString();
110+
return (
111+
content.includes('it.only') ||
112+
content.includes('describe.only') ||
113+
content.includes('fdescribe') ||
114+
content.includes('fit(')
115+
);
116+
});
117+
raiseIssueAboutPaths(fail, onlyTestFiles, 'an `only` was left in the test');
118+
119+
// Politely ask for their name in the authors file
120+
message('Please add your name and email to the AUTHORS file (optional)');
121+
message(
122+
'If this was a change that affects the external API, please update the docs and post a link to the PR in the discussion'
123+
);
124+
}

0 commit comments

Comments
 (0)