status-im
/
sourcecred
mirror of https://github.com/status-im/sourcecred.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
sourcecred/config/paths.js

42 lines
1.5 KiB
JavaScript
Raw Normal View History

Fix flow errors in paths.js (#238) - Fix accidental string-to-NaN coercion in ensureSlash - Don't dynamically require package.json; to determine public url, just use the environment variable or "/" Test plan: `yarn start` and travis still work
2018-05-08 21:21:19 +00:00
// @flow
Run `yarn prettify` for the first time. (#22)
2018-02-18 16:13:29 +00:00
const path = require("path");
const fs = require("fs");
Eject from create-react-app (#19) 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
2018-02-17 21:28:47 +00:00
// Make sure any symlinks in the project folder are resolved:
// https://github.com/facebookincubator/create-react-app/issues/637
const appDirectory = fs.realpathSync(process.cwd());
Run `yarn prettify` for the first time. (#22)
2018-02-18 16:13:29 +00:00
const resolveApp = (relativePath) => path.resolve(appDirectory, relativePath);
Eject from create-react-app (#19) 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
2018-02-17 21:28:47 +00:00
// config after eject: we're in ./config/
module.exports = {
new-webpack: clean `build/` before prod (#568) Summary: In our current system, we build by invoking `scripts/build.js`, which begins by removing the `build/` directory. This behavior is nice, because it prevents cross-contamination between builds. In this commit, we add a plugin to achieve the same result from directly within Webpack. Test Plan: Run ``` mkdir -p ./build touch ./build/wat NODE_ENV=production node ./node_modules/.bin/webpack \ --config config/makeWebpackConfig.js ``` and ensure that `./build/wat` does not exist after the build completes. wchargin-branch: webpack-clean-build
2018-07-31 01:01:47 +00:00
root: appDirectory,
Run `yarn prettify` for the first time. (#22)
2018-02-18 16:13:29 +00:00
dotenv: resolveApp(".env"),
Add a favicon (#637) Summary: In addition to the obvious benefit of having a favicon, this gets rid of a 404 Not Found error on our home page, tremendously boosting our hacker cred. Test Plan: The favicon is displayed in both `yarn start` and the static site (as a result of the build script). The added build test fails before this change. wchargin-branch: add-favicon
2018-08-10 20:15:49 +00:00
favicon: resolveApp("src/assets/logo/sourcecred_32.png"),
Run `yarn prettify` for the first time. (#22)
2018-02-18 16:13:29 +00:00
appBuild: resolveApp("build"),
Change `src/v3/` to `src/` and remove v3 naming (#474) Test plan: `git grep -i v3` only shows incidental hits in longer strings `yarn travis --full` passes `yarn backend` works `yarn build` works `yarn start` works `node bin/sourcecred.js start` works `node bin/sourcecred.js load sourcecred example-github` works Paired with @wchargin
2018-06-30 23:01:54 +00:00
appIndexJs: resolveApp("src/app/index.js"),
Implement a first-pass static site generation Summary: Some of the code here is adapted from my site (source available on GitHub at wchargin/wchargin.github.io). It has been improved when possible and made worse when necessary to fit into our existing build system with minimal churn. As of this commit, there remain the following outstanding tasks: - Use a non-hardcoded list of paths in static site generation router. This is not trivial. We have the paths nicely available in `routes.js`, but this module is written in ES6, and transitively depends on many files written in ES6 (i.e., the whole app). Yet naïvely it would be required from a Webpack config file, which is interpreted as vanilla JavaScript. - Add `csso-loader` to minify our CSS. This is easy. - Add unit tests for `dedent`. (As is, it comes from my site verbatim. I wrote it. dmnd’s `dedent` package on npm is insufficient because it dedents arguments as well as the format string, which is incorrect at least for our purposes.) - Link in canonical static data for the site. - Rip out the whole build system and replace it with my build config, which is orders of magnitude saner and less bad. (By “the whole build system” I mostly mean `webpack.config.{dev,prod}.js`.) Test Plan: ```shell $ yarn backend $ yarn build $ node ./bin/sourcecred.js start ``` wchargin-branch: static-v0
2018-07-21 06:19:40 +00:00
appServerSideRenderingIndexJs: resolveApp("src/app/server.js"),
Use route data for static site source of truth Summary: This removes the hard-coded route data from the Webpack config, replacing it with the list of paths exported by the route data module. Test Plan: Note that the output of `yarn build` is identical before and after this change: namely, ```shell $ find build -exec shasum -a 256 {} + | shasum -a 256 7610a61f8a977f1d8edd849fc81256ca15f41f366e5fdb4b59a5d5ce37d6d58e ``` wchargin-branch: non-hard-coded-route-data
2018-07-23 19:31:00 +00:00
appRouteData: resolveApp("src/app/routeData.js"),
Run `yarn prettify` for the first time. (#22)
2018-02-18 16:13:29 +00:00
appPackageJson: resolveApp("package.json"),
appSrc: resolveApp("src"),
yarnLockFile: resolveApp("yarn.lock"),
appNodeModules: resolveApp("node_modules"),
Configure Webpack for backend applications (#84) Summary: Running `yarn backend` will now bundle backend applications. They’ll be placed into the new `bin/` directory. This enables us to use ES6 modules with the standard syntax, Flow types, and all the other goodies that we’ve come to expect. A backend build takes about 2.5s on my laptop. Created by forking the prod configuration to a backend configuration and trimming it down appropriately. To test out the new changes, this commit changes `fetchGitHubRepo` and its driver to use the ES6 module system and Flow types, both of which are properly resolved. Test Plan: Run `yarn backend`. Then, you can directly run an entry point via ``` $ node bin/fetchAndPrintGitHubRepo.js sourcecred example-repo "${TOKEN}" ``` or invoke the standard test driver via ```shell $ GITHUB_TOKEN="${TOKEN}" src/backend/fetchGitHubRepoTest.sh ``` where `${TOKEN}` is your GitHub authentication token. wchargin-branch: webpack-backend
2018-03-19 05:43:23 +00:00
backendBuild: resolveApp("bin"),
// This object should have one key-value pair per entry point. For
// each key, the value should be the path to the entry point for the
// source file, and the key will be the filename of the bundled entry
// point within the build directory.
backendEntryPoints: {
Replace `oclif` with `cli` (#744) Summary: This commit changes the CLI to use the code in `cli` instead of `oclif`. A subsequent commit will remove the dependency on OClif altogether. Resolves #580. Test Plan: Note that `yarn backend; node bin/sourcecred.js help` works. Note that the documentation in the README is still correct. wchargin-branch: cli-replace-oclif
2018-09-02 23:11:56 +00:00
sourcecred: resolveApp("src/cli/main.js"),
Save the GitHub relational store from the CLI (#447) Summary: This provides a command-line entry point `load-plugin-v3` (which will become `load-plugin` eventually), which fetches the GitHub data via GraphQL and saves the resulting `RelationalStore` to disk. A change to the Babel config is needed to prevent runtime errors of the form `_callee7` is not defined, where `_callee7` is a gensym that is appears exactly once in the source (in use position, not definition position). I’m not sure exactly what is causing the error or why this config change fixes it. But while this patch may be fragile, I don’t think that it’s likely to subtly break anything, so I’m okay with pushing it for now and dealing with any resulting breakage as it arises. Paired with @decentralion. Test Plan: Run `yarn backend`, then run something like: ``` node bin/sourcecredV3.js load-plugin-v3 \ sourcecred example-github --plugin github ``` Inspect results in `SOURCECRED_DIR/data/OWNER/NAME/github/view.json`, where `SOURCECRED_DIR` is `/tmp/sourcecred` by default, and `OWNER` and `NAME` are the repository owner and name. This example repository takes about 1.1 seconds to run. The SourceCred repository takes about 45 seconds. wchargin-branch: cli-load-plugin
2018-06-29 19:12:37 +00:00
//
github: add GraphQL schema and Flow types (#928) Summary: The included schema is forked from the one in `graphql/demo.js`. Primitive types have been added, and the `parents` connection has been added to commit objects per #920. (We do not include this in the demo script because without prefetching it would take a long time to load.) Test Plan: Unit tests added; run `yarn unit`. Then run `yarn backend` and verify that `node ./bin/generateGithubGraphqlFlowTypes.js` generates exactly the same output as in the types file: ``` $ node ./bin/generateGithubGraphqlFlowTypes.js | > diff -u - ./src/plugins/github/graphqlTypes.js $ echo $? 0 ``` Change the `graphqlTypes.js` file and verify that `yarn unit` fails. As the build config has been changed, a `yarn test --full` is warranted. It passes. Finally, I have manually verified that the schema is consistent with the documentation at <https://developer.github.com/v4/object/repository/> and related pages. wchargin-branch: github-schema-flow-types
2018-10-19 16:04:54 +00:00
generateGithubGraphqlFlowTypes: resolveApp(
"src/plugins/github/bin/generateGraphqlFlowTypes.js"
),
Change `src/v3/` to `src/` and remove v3 naming (#474) Test plan: `git grep -i v3` only shows incidental hits in longer strings `yarn travis --full` passes `yarn backend` works `yarn build` works `yarn start` works `node bin/sourcecred.js start` works `node bin/sourcecred.js load sourcecred example-github` works Paired with @wchargin
2018-06-30 23:01:54 +00:00
fetchAndPrintGithubRepo: resolveApp(
"src/plugins/github/bin/fetchAndPrintGithubRepo.js"
Port GitHub data ingestion into v3 (#378) This commit copies the following logic necessary for downloading GitHub data into v3. Minimal changes have been made to accomodate the new path structure. Test plan: - Manually ran plugins/github/fetchGithubRepoTest.sh and verified that it can correctly pass and fail - Added the v3 github repo test to `yarn travis --full` - Ran `yarn travis --full` and it passed Paired with @wchargin
2018-06-12 01:57:37 +00:00
),
Change `src/v3/` to `src/` and remove v3 naming (#474) Test plan: `git grep -i v3` only shows incidental hits in longer strings `yarn travis --full` passes `yarn backend` works `yarn build` works `yarn start` works `node bin/sourcecred.js start` works `node bin/sourcecred.js load sourcecred example-github` works Paired with @wchargin
2018-06-30 23:01:54 +00:00
createExampleRepo: resolveApp("src/plugins/git/bin/createExampleRepo.js"),
mirror: add an end-to-end `update` function (#909) Summary: This completes the minimum viable public API for the `Mirror` class. As described on the docstring, the typical workflow for a client is: - Invoke the constructor to acquire a `Mirror` instance. - Invoke `registerObject` to register a root object of interest. - Invoke `update` to update all transitive dependencies. - Invoke `extract` to retrieve the data in structured form. It is the third step that is added in this commit. In this commit, we also include a command-line demo of the Mirror module, which exercises exactly the workflow above with a hard-coded GitHub schema. This can be used to test the module’s behavior with real-world data. I plan to remove this entry point once we integrate this module into SourceCred. This commit makes progress toward #622. Test Plan: Unit tests included for the core functionality. The imperative shell does not have automated tests. You can test it as follows. First, run `yarn backend` to build `bin/mirror.js`. Then, run: ```shell $ node bin/mirror.js /tmp/mirror-demo.db \ > Repository MDEwOlJlcG9zaXRvcnkxMjMyNTUwMDY= \ > 60 ``` Here, the big base64 string is the ID for the sourcecred/example-github repository. (This is listed in `graphql/demo.js`, alongside the ID for the SourceCred repository itself.) The value 60 is a TTL in seconds. The database filename is arbitrary. This will print out a ton of output to stderr (all intermediate queries and responses, for debugging purposes), and then the full contents of the example repository to stdout. Run the command again, and it should finish instantly. On my machine, the main function runs faster than the Node startup time (50ms vs 60ms). Then, re-run the command, changing the TTL from `60` to `1`. Note that it sends off some queries and then prints the same repository. It is safe to kill the program at any time, either while waiting for a response from GitHub or while processing the results, because the mirror module takes advantage of SQLite’s transaction-safety. Intermediate updates will be persisted, so you’ll lose just a few seconds of progress. You can also of course dive into the generated database yourself to explore the data. It’s good fun. wchargin-branch: mirror-e2e-update
2018-10-03 04:06:01 +00:00
mirror: resolveApp("src/graphql/demo.js"),
Configure Webpack for backend applications (#84) Summary: Running `yarn backend` will now bundle backend applications. They’ll be placed into the new `bin/` directory. This enables us to use ES6 modules with the standard syntax, Flow types, and all the other goodies that we’ve come to expect. A backend build takes about 2.5s on my laptop. Created by forking the prod configuration to a backend configuration and trimming it down appropriately. To test out the new changes, this commit changes `fetchGitHubRepo` and its driver to use the ES6 module system and Flow types, both of which are properly resolved. Test Plan: Run `yarn backend`. Then, you can directly run an entry point via ``` $ node bin/fetchAndPrintGitHubRepo.js sourcecred example-repo "${TOKEN}" ``` or invoke the standard test driver via ```shell $ GITHUB_TOKEN="${TOKEN}" src/backend/fetchGitHubRepoTest.sh ``` where `${TOKEN}` is your GitHub authentication token. wchargin-branch: webpack-backend
2018-03-19 05:43:23 +00:00
},
Eject from create-react-app (#19) 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
2018-02-17 21:28:47 +00:00
};