Summary:
We need this for testing graph equality: deep-equality is not sufficient
because two graphs can be logically equal even if, say, two nodes are
added in different orders.
This commit adds a dependency on `lodash.isequal` for deep equality.
Test Plan:
New unit tests added. Run `yarn flow && yarn test`.
wchargin-branch: graph-equals
Summary:
In merging #54, there was a semantic merge conflict that was not also a
textual merge conflict; this created a failure that only appeared once
that commit was merged.
We propose that to fix this in the future, we only merge commits that
are directly ahead of master.
Test Plan:
This fixes `yarn flow` and `yarn test`.
wchargin-branch: fix-merge-conflict
Summary:
Again: we assume these invariants, so we may as well encode them.
We should just keep in mind that non-Flow users may wantonly violate
these, so we should still code defensively.
wchargin-branch: readonly-exact
Summary:
These will make nicer error functions in cases where static analysis
doesn’t detect the pollution: e.g., a user isn’t using Flow, or an
expression like `arr[0]` introduces an `undefined`.
Paired with @dandelionmane.
Test Plan:
New unit tests added. Run `yarn test`.
wchargin-branch: null-undefined-check
Create an 'advancedMealGraph' test case
The advancedMealGraph will be a grab-all that holds all advanced and
edge behaviors, e.g. the crab-self-referential loop, and the case
where there are multiple directed edges between the same two nodes.
Aggregating them into one test case will make it easier to test more
complex behaviors, like graph merging and serialization, on the
edge case graphs. However, it's still nice to have the simple graph
so that we can test simple things too. The specific tests for edge
case behavior are left mostly unchanged, in that they start from the
simple graph and add just the advanced feature that they want to test.
Summary:
Without these functions, it is not possible to meaningfully operate on
an arbitrary graph.
Paired with @dandelionmane.
Test Plan:
New unit tests included. Run `yarn flow && yarn test`.
wchargin-branch: get-all
Summary:
We’ve realized that `u: Edge<T>` implies `u: Node<T>`. That certainly
wasn’t what we were expecting! We might want something like that
eventually, to capture the fact that valuations are themselves valuable,
but for now the type system should encode the assumptions that we’re
actually making. See also #50.
Paired with @dandelionmane.
wchargin-branch: exact-types
Summary:
We had planned to expose our core types as simple Plain Old JavaScript
Objects, with accompanying standalone functions to act directly on these
data structures. We chose this instead of creating `class`es for the
types because it simplifies serialization interop: it obviates the need
for serialization and deserialization functions, because the code is
separated from the data entirely. Reconsidering, we now think that the
convenience benefits of using classes probably outweigh these
serialization cons. Furthermore, this design enables us to separate
ancillary data structures and caches from the raw data, presenting a
cleaner API for consumers of the data.
This commit introduces a `Graph` class and some related logic. With lots
of tests! And 100% code coverage! :-)
Paired with @dandelionmane.
Test Plan:
Run `yarn flow && yarn test` to see the new tests.
wchargin-branch: graph-class
Summary:
The main problem with having these fields on the node is that this
presents the illusion that the API surface area is larger than it
actually is. Clients with reference to a node object could
somewhat-reasonably expect that mutating these fields would be
sufficient to update the structure of the graph, but this isn’t the case
(as the edge objects would need to be updated, too). It’s a nice
semantic bonus, too, as edges aren’t conceptually “part of” nodes.
wchargin-branch: top-level-edges
Summary:
This is an experiment. There are a couple diffferent meanings of
“weight” in play: most prominently, weights assigned by plugins versus
those suitable for comparison among other arbitrary weights. We’re not
sure what the right thing is to put in the actual graph object, so we’re
going to think about this a bit more before adding the field back in.
wchargin-branch: remove-weights
Summary:
The “ID” parts were left-over from the Great Address Migration, and we
think that abbreviations are fine here, anyway.
Test Plan:
`yarn flow && yarn test`
wchargin-branch: src-dst-rename
design.md and overview.md both describe a vision of sourcecred
in which it is a measure of credit, and an explicit cryptographic
token. right now, SourceCred is more focused on just measuring credit,
with the expectation that cryptoincentives can be added on later.
Removing these outdated documents will reduce confusion; they may
be re-written and re-added later.
Summary:
The sourcecred/tiny-example-repository repository stores some example
data that we can use to generate test cases. As of now, the repository
has been archived so that its state is stable. This commit checks in the
result of our scraper on the repository.
wchargin-branch: example-data
Reorganize the code so that we have a single package.json file, which is at the root.
All source code now lives under `src`, separated into `src/backend` and `src/explorer`.
Test plan:
- run `yarn start` - it works
- run `yarn test` - it finds the tests (all in src/explorer) and they pass
- run `yarn flow` - it works. (tested with an error, that works too)
- run `yarn prettify` - it finds all the js files and writes to them
Summary:
This tool grabs all the information that we think will be relevant for a
first-pass implementation of the SourceCred project graph. It includes a
tool to save the results to disk so that we avoid needlessly hitting the
GitHub API over and over.
Paired with @dandelionmane.
Test Plan:
The API doesn’t have tests, because we didn’t think that they would
provide much marginal value. But here’s how you invoke it:
node bin/fetchAndPrintGitHubRepo.js sourcecred sourcecred "${TOKEN}" >/tmp/out
to crawl the repository `sourcecred/sourcecred` with the given API
token.
wchargin-branch: grab-github-data
This reflects our current vision that SourceCred is aimed at valuing open-source contributions via a credit graph, not on directly creating cryptotokens
* Use font roboto
* Change title.
* Add grid gap
* Restyle app; blue header, and css->inline.
* Further visual cleanup.
- Apply consistent formatting to the two plugin panes.
- Add scroll to the User Explorer.
- Both have white backgrounds with centered titles.
Setup prettier precommit, with yarn prettify to reformat.
- Prettier runs as a precommit hook and fails if code is improperly formatted.
- Run `yarn prettify` to reformat the project.
Summary:
Closes#17; see discussion there.
This commit uses the `babel-plugin-flow-react-proptypes` package to
automatically create PropType definitions from components that are typed
with Flow. It simultaneously updates all of our existing components to
be typed with Flow. As a result, we have both static and dynamic type
checking.
Test Plan:
Note that `yarn test` and `yarn flow` report no errors, and that there
are no prop validation errors at runtime with `yarn start`.
Then, apply the following patch:
```diff
diff --git a/explorer/src/UserExplorer.js b/explorer/src/UserExplorer.js
index bb574cd..636a10d 100644
--- a/explorer/src/UserExplorer.js
+++ b/explorer/src/UserExplorer.js
@@ -18,7 +18,7 @@ export class UserExplorer extends Component<{
.sort((a,b) => b[1] - a[1]);
const entries = sortedUserWeightTuples.map(authorWeight => {
const [author, weight] = authorWeight;
- return <UserEntry userId={author} weight={weight} key={author}/>
+ return <UserEntry userId={55} weight={weight} key={author}/>
});
return <div className="user-explorer">
<h3> User Explorer </h3>
```
Note that `yarn test` fails (the `App.test.js` E2E rendering test),
`yarn flow` fails, and there is a runtime prop validation error.
wchargin-branch: autogenerate-proptypes
Summary:
This commit was created by performing the following steps:
- `rm -r node_modules`
- `yarn install`
- `yarn eject`
- `rm -r node_modules`
- `yarn install`
on an environment wit Node v6.11.1.
The final `rm -r node_modules && yarn install` ensures that the
`yarn.lock` file is updated accordingly.
Test Plan:
`yarn test`, `yarn flow`, and `yarn start` all still do the right thing.
wchargin-branch: eject
Summary:
This should ensure that there aren’t any runtime PropTypes errors.
The change to reimplement `Object.entries` is due to the fact that my
local Node environment (v6.11.1) does not yet support that ESnext
function.
Test Plan:
Apply the following diff (`git apply`):
```diff
diff --git a/explorer/src/UserExplorer.js b/explorer/src/UserExplorer.js
index 8da252d..cdc1370 100644
--- a/explorer/src/UserExplorer.js
+++ b/explorer/src/UserExplorer.js
@@ -10,7 +10,7 @@ export class UserExplorer extends Component {
static propTypes = {
selectedPath: PropTypes.string.isRequired,
selectedUser: PropTypes.string,
- onSelectUser: PropTypes.func.isRequired,
+ onSelectUser: PropTypes.number.isRequired,
data: commitUtilsPropTypes.commitData.isRequired,
}
```
Then, `yarn test` should fail. Revert the diff, and `yarn test` should
pass.
wchargin-branch: react-proptypes-test
Test Plan:
Run `yarn start` and note that the app runs without any console
warnings, but that changing some of the PropTypes to introduce an error
actually does cause a warning. Upcoming: an automatic test for this.
wchargin-branch: add-proptypes
Sets up an initial cred explorer that looks at Git commit data
- uses git commit data as generated by `experiments/01_commit_graph_dump.ipynb`
- displays a file explorer, which lets you navigate the file tree by expanding/collapsing dirs, and select a path via double clicking (changes background color)
- displays a user explorer, which shows a sorted list of authors and cred amounts for the selected file path
The commit-wrangling logic is in commitUtils.js and has typechecking (via flow) and some basic testing.
The frontend is built with react; setup was bootstrapped via create-react-app.
Test plan:
```
cd explorer;
yarn install; # get dependencies
yarn flow; # check that types check out
yarn test; # check that tests pass, then `q`
yarn start; # go to localhost:3000 and click around
```
expected behavior: there's a file explorer that shows TensorBoard file structure on the left. you can click the buttons to explore directory, and you can click files to select that path. on the right, it shows you the users that contributed to that directory and their cred for those commits.
note: the ui is very crude.
* Initial infrastructure for sourcecred-explorer.
Setup npm, yarn, flow, jest using scaffolding from
create-react-app.
- used create-react-app to get the basic pieces
- added support for flow via instructions in the
create-react-app user guide
- added flow-typed so that flow+jest will work well
* Add some additional resources
* Add index.css
* Remove .DS_STORE per @wchargin's suggestion
commit_graph_dump is modified to use camelCase variables
in the output data.json. Saved the data for TensorBoard
in explorer/src/data.json, where it's useful for debugging
/ iterating on the frontend.
Summary:
This is a minimal script that will crawl the file-reachable commits in a
repository and dump statistics to a JSON file that can be further
analyzed interactively on a frontend.
Requires PyPI `gitpython` (and `matplotlib`, but this can be excised).
Requires `jupyter` to run.
(Mostly paired with @dandelionmane on 2018-02-08.)
wchargin-branch: experiment-commit-traversal
Summary:
This changes the titles of two design goals so that they are all
adjectival: “SourceCred will be…” and not “SourceCred will have…”.
wchargin-branch: design-goals-grammar-list-consistent
William Chargin
Dandelion Mané