Summary:
The `sourcecred site` command now sets up a static site for a cred
instance, which may be deployed to (e.g.) GitHub Pages or IPFS.
This implementation sets up a directory structure where the site is
contained in a `site/` subdirectory whose top-level entries are also
symbolically linked from the root of the instance. Thus:
```
my-instance/
sourcecred.json
config/
output/
site/
index.html
favicon.png
static/
static/js/...
index.html -> site/index.html
favicon.png -> site/favicon.png
static -> site/static
```
The purpose of this is to enable the instance to be served directly as a
GitHub Pages site without the user having to navigate to a URL that
includes a `site/` path component.
It’s not a perfect solution. The top level of the instance is cluttered.
If we have any web pages other than the root directory, then they’ll
appear at top level, too. If we change the structure, we’ll need to
teach `sourcecred site` to clean up vestiges of old structures. We also
won’t be able to have any pages called `config` or `output` or `cache`
due to namespace collision. But we think that it’s at least a reasonable
stopgap, and doesn’t incur much conceptual overhead.
This isn’t tested or officially supported on Windows.
Paired with @decentralion.
Test Plan:
Run `yarn build` to build the frontend and backend, then `cd` into a
SourceCred instance and run `node "${OLDPWD}/bin/sourcecred.js site`.
Note that a `site/` directory is created, and when the static site is
served it works from either `site/` or the instance root. Note that this
all works when actually deployed to GitHub Pages as well.
wchargin-branch: cli-site
Summary:
Previously, we used `backend` to build the backend and `build` to build
the frontend, which was a bit confusing. Now, `build:backend` and
`build:frontend` build the respective components, and `build` builds
both in parallel.
Test Plan:
Run `rm -r bin build` and then `yarn build`, and note that the `bin` and
`build` directories are recreated.
wchargin-branch: build-unified-cmd
This commit integrates a new version of the cred explorer, which is
compatible with the new instance-based cred. It combines some of the
benefits of the v1 explorer (shows cred source decomposition) and the v2
explorer (shows cred-over-time for users). It's still very basic, and it
lacks an important feature of both v1 and v2 in that it doesn't allow
recomputing cred scores with new weights.
Nonetheless, it's a big improvement over having no functional ui at all!
Test plan: Manually test with a real instance, e.g. via
`yarn start --instance $PATH`
Summary:
One weird hack needs to be slightly amended; everything else still works
given recent changes to suppression comments.
Test Plan:
Running `yarn flow` passes as is, but fails if a suppression comment is
removed.
wchargin-branch: flow-v0.127.0
Now that we're making the new UI the canonical one, we can remove
references to calling it `build2` or `start2`.
Test plan: `yarn start --instance $PATH` and `yarn build` both work.
`yarn test --full` passes.
The cli2 ("instance") system has a foundationally different assumption
about how the frontend works: rather than having a unified frontend that
abstracts over many separate SourceCred projects, we'll have a single
frontend entry per instance. This means we no longer need (for example)
to make project IDs available at build time.
Our frontend setup and server side rendering is pretty complex, so
rather than rebuild it from scratch, I'm going to fork it into an
independent copy and then change it to suit our needs.
To start here, I've duplicated the `src/homepage` directory into
`src/homepage2`, duplicated the webpack config to
`config/webpack.config.web2.js`, and duplicated the paths and
package.json scripts.
Test plan:
Run `yarn start2` and it will start an identical frontend, using the
duplicated directory. Run `yarn build2` and it will build a viable
frontend into the `build2` directory. `build2` is gitignored.
This includes packages that can be upgraded without making changes.
* Chore: minor version upgrades
* Chore: upgrade fs-extra
* Chore: upgrade chalk
* Chore: upgrade jest, babel-jest
Closes#1712Closes#1734
Summary:
Prettier 2.0.0 introduced some far-reaching formatting changes, so this
commit temporarily neutralizes `check-pretty`. Follow-up commits will
update all formatting and re-enable the package script.
Generated with `yarn add prettier@^2.0.1`.
Test Plan:
Running `yarn check-pretty` prints a bunch of files and then the
expected “Failures OK” message, exiting 0.
wchargin-branch: prettier-2.0.1-upgrade
This commit adds a `grain/grain.js` module, which contains a type and
logic for representing Grain balances with 18 digits of precision. We
use the native BigInt type (and add the necessary babel plugin to
support it).
Unfortunately, Flow does not yet support BigInts (see
[facebook/flow#6639]). To hack around this, we lie to Flow, claiming
that BigInts are numbers, and we expect/suppress the flow errors
whenever we actually instantiate one. For example:
```js
// $ExpectFlowError
const myBigInt = 5n;
```
We can use the BigInt operators like `+`, `-`, `>` without flow errors,
since these actually exist on numbers too. However, flow will fail to
detect improper combinations of regular numbers and BigInts:
```js
// $ExpectFlowError
const x = 5n;
const y = x + 5;
// Uncaught TypeError: Cannot mix BigInt and other types
```
Since any improper mixing will result in a runtime error, these issues
will be easy to detect via unit tests.
In addition to adding the basic Grain type, I exported a `format`
function which will display Grain balances in a human readable way.
It supports arbitrary decimal precision, groups large amounts with comma
separators, handles negative numbers, and adds a suffix string.
The format method is thoroughly documented and tested. Thanks to @Beanow
for valuable feedback on its implementation.
Test plan: See included unit tests. `yarn test` passes.
[facebook/flow#6639]: https://github.com/facebook/flow/issues/6639
Preparing for release #1679
Note: due to a regression, not upgrading eslint-plugin-react
See https://github.com/yannickcr/eslint-plugin-react/issues/2570
Also updated package.json to latest semver in-range versions.
Note, this changes all packages (other than eslint-plugin-react)
to ^x.x.x format.
Helper functions intended to be used in succession by `loadDirectory`.
Only `_validatePath` provides helfpul error messages. It's the caller's
responsiblity to do this first.
Introduces dependency `globby` for globbing with a Promises API.
* chore(package): update flow-bin to version 0.117.0
* chore(package): update lockfile yarn.lock
* Fixup flow error
From the [Flow 0.117.0 release notes](https://github.com/facebook/flow/releases/tag/v0.117.0)
> Removed uses of Symbol from libdefs in favor of symbol.
Test plan: `yarn flow`
Co-authored-by: Dandelion Mané <decentralion@dandelion.io>
Summary:
This re-packages the build for the internal APIs exposed under #1526 to
be more browser-friendly. Removing `target: "node"` (and adding an
explicit `globalObject: "this"` for best-effort cross-compatibility) is
the biggest change from the backend build; removing all the extra
loaders and static site generation is the biggest change from the
frontend build.
This build configuration is forked from `webpack.config.backend.js`.
Test Plan:
Run `yarn api`, then upload the contents of `dist/api.js` to an
Observable notebook and require it as an ES module. Verify that the
SourceCred APIs are exposed: e.g., `sourcecred.core.graph.Graph` should
be a valid constructor.
wchargin-branch: api-build
* chore(package): yarn upgrade
Updates all packages within version range.
* Bugfix update stacktrace matching code
The stacktrace has changed, most likely due to
a babel plugin updating. It now seems based on
the name of the `handlingErrors` argument
instead of the variable name storing the
anonymous function.
* Bugfix update react-router patch version
By updating the react packages, warnings were
logged about unsafe componentWillMount usage.
These warnings tripped a unit test.
react-router was the cause of these, so this
update avoids getting the warnings.
Summary:
Most changes due to <https://github.com/prettier/prettier/pull/6694>.
Generated with `yarn add prettier@1.19.1 && yarn prettify`.
Test Plan:
Running `yarn test` suffices.
wchargin-branch: prettier-v1.19.1
Summary:
The Flow team fixed a lot of bugs related to object spreading recently.
Some of these enable us to simplify our code (`generateGraphqlFlowTypes`
and `mirror`). Some find new genuine errors. Others require suppressions
in place of a larger change.
Test Plan:
Running `yarn flow` now passes.
wchargin-branch: upgrade-flow-v0.111.0
This commit adds a `parseLinks` method to a new module,
`plugins/discourse/references`. `parseLinks` allows us to extract the
hyperlinks from `<a>` tags in "cooked" html.
I added `htmlparser2` as a dependency to parse the html. There were a
lot of options to choose from; I chose htmlparser2 because it has a lot
of usage, reasonable performance, and suits our needs. We use this
dependency in a lightweight and local way, so we can always change it
later if needed.
One thing which was a bit odd: I wasn't able to import it using
`import`, and needed a `require` statement instead.
Test plan: Unit tests added; `yarn test` passes.
This is progress towards [Discourse reference and mention detection][1].
[1]: https://discourse.sourcecred.io/t/discourse-reference-mention-detection/270
We need one tiny change in test code, where Flow (correctly) detects an
error. I've added an error suppression comment because it is truly a
Flow error, but is appropriate as we are testing an error condition.
Test plan: `yarn test`
Summary:
Upgrading past a security fix in that package. Generated by running
`yarn add eslint@^6.2.2 babel-eslint@^10.0.3`: `eslint` to update the
problematic transitive dependency, and `babel-eslint` to avoid
<https://github.com/eslint/eslint/issues/12117>.
Test Plan:
Running `yarn lint` yields no false positives, and does complain on true
positives. Running `yarn list --pattern eslint-utils` lists only v1.4.2.
wchargin-branch: eslint-utils-1.4.2
This implements rate limiting to the Discourse fetch logic, so that we
can actually load nontrivial servers without getting a 529 failure.
We could have used retry; I thought it was more polite to actually limit
the rate at which we make requests. However, to avoid seeing 529s in
practice, I left a bit of a buffer: we make only 55 requests per minute,
although 60 would be allowed.
If we want to improve Discourse loading time, we could boost up to the
full 60 request/min, but add in retries. (Or we could switch to retries
entirely.)
Test plan: This logic is untested, however my full discourse-plugin
branch uses it to do full Discourse loads without issue.
I'm mostly motivated by wanting to get greenkeeper lockfile
auto-updating working (see #1269) although this is also a first step
towards making SourceCred usable from NPM (#1232).
For now, see this as us making sure we claim the sourcecred package name
on npm (see: https://www.npmjs.com/package/sourcecred).
I also fixed the license spec so that it's valid SPDX.
