* ci - run storybook and add to build-artifacts
* ci/storybook - rename storybook build path and fix artifact upload
* ci/storybook - rename link text
* clean - remove accidently committed storybook build dir
* storybook - fix image path to relative (#10364)
We don't look at coveralls very much. We might occasionally consult it
to see a report on our code coverage, but that report is already
generated entirely locally, and has been added to the MetaMask bot
comment in #10061.
The `build-artifacts` directory is created on CI (as of #7151), and is
used to store the sesify visualization and dependency logs. It's useful
to have this ignored locally as well, for when those scripts are being
tested.
The `build-artifacts` directory is created on CI (as of #7151), and is
used to store the sesify visualization and dependency logs. It's useful
to have this ignored locally as well, for when those scripts are being
tested.
The remaining integration tests are all covered by e2e tests, so
they're no longer needed.
All associated scripts, fixtures, and dependencies have also been
removed.
Our JSDoc documentation has not been updated in a very long time, and
we don't use JSDoc in enough places for the docs to have been
especially useful. The tools and scripts used to generate and publish
these docs have been removed.
References to this documentation have also been removed from the
README.
Hopefully once the TypeScript migration has made substantial progress,
we can generate more useful documentation using something like TypeDoc.
As a solution to the constant lockfile churn issues we've had with
`npm`, the project now uses `yarn` to manage dependencies.
The `package-lock.json` file has been replaced with `yarn.lock`, which
was created using `yarn import`. It should approximate the contents of
`package-lock.json` fairly well, though there may be some changes due to
deduplication. The codeowners file has been updated to reference this
new lockfile.
All documentation and npm scripts have been updated to reference `yarn`
rather than `npm`. Note that running scripts using `npm run` still works
fine, but it seemed better to switch those to `yarn` as well to avoid
confusion.
The `npm-audit` Bash script has been replaced with `yarn-audit`. The
output of `yarn audit` is a bit different than `npm audit` in that it
returns a bitmask to describe which severity issues were found. This
made it simpler to check the results directly from the Bash script, so
the associated `npm-audit-check.js` script was no longer required. The
output should be exactly the same, and the information is still sourced
from the same place (the npm registry).
The new `yarn-audit` script does have an external dependency: `jq`.
However, `jq` is already assumed to be present by another CI script, and
is present on all CI images we use. `jq` was not added to `package.json`
as a dependency because there is no official package on the npm
registry, just wrapper scripts. We don't need it anywhere exept on CI
anyway.
The section in `CONTRIBUTING` about how to develop inside the
`node_modules` folder was removed, as the advice was a bit dated, and
wasn't specific to this project anyway.
The npm audit script was auditing all dependencies, then filtering the
results to just the advisories concerning production dependencies. This
was done by checking the boolean `dev` and `optional` properties of each
`findings` entry in each advisory.
The `dev` and `optional` properties are now missing, which is resulting
in dev advisories being mistakenly identified as affecting production.
This check has been removed, and instead the `--production` flag is used
when calling `npm audit`. This accomplishes the same goal without
relying as much upon the audit output format.
The `--production` flag was added in `npm` `v6.10.0`, so `npm` has been
updated to the current latest stable (`v6.10.2`) for the `test-deps`
job. It was also updated on the `prep-deps-npm` job to ensure
consistency in behaviour. The other jobs only use `npm run` which hasn't
changed substantially in some time, so compatibility isn't really a
concern for those.
`audit.json` has also been added to `.gitignore`. It was accidentally
checked in once while working on this branch.
* ci: Rename full_test to test_and_release
* ci: Add scripts to automate GH releases
* Add .bak files to .gitignore
* ci: Add reviewer to the auto version PR
The `disc` gulp command no longer works. I wasn't able to fix this
easily, so instead it has been removed. We can probably find something
better to replace it with.
* Add UI Testing Framework and Simple UI Test
Added a Testem configuration that launches a Qunit page with an iFrame that builds and loads our mock-dev page and can interact with it and run tests on it.
Wrote a simple test that accepts the terms and conditions and transitions to the next page.
I am not doing any fancy redux-hooks for the async waiting, I've simply added a `tests/integration/helpers.js` file with a `wait()` function that returns a promise that should wait long enough.
Long term we should hook into the app lifecycle by some means for testing, so we only wait the right amount of time, and wait long enough for slower processes to complete, but this may work for the time being, just enough to run some basic automated browser tests.
* Separate UI tests from normal unit test suite
* Add UI tests to CI test script
* Add testem and phantom to circleCI pre-script
* Fix circle pre script
* Move pre scripts to dependencies key
* Remove phantom from build deps
* Fix testem runner page
* Add promise polyfill for PhantomJS
* Skip PhantomJS in testem
* Run browser tests in parallel
* Fix promise usage?
* Correct skip usage
Added a Testem configuration that launches a Qunit page with an iFrame that builds and loads our mock-dev page and can interact with it and run tests on it.
Wrote a simple test that accepts the terms and conditions and transitions to the next page.
I am not doing any fancy redux-hooks for the async waiting, I've simply added a `tests/integration/helpers.js` file with a `wait()` function that returns a promise that should wait long enough.
Long term we should hook into the app lifecycle by some means for testing, so we only wait the right amount of time, and wait long enough for slower processes to complete, but this may work for the time being, just enough to run some basic automated browser tests.
kumavis
Mark Stacey
ricky
Whymarrh Whitby
brunobar79
William Morriss
kumavis
bitpshr
Lazaridis
Clark, Jason (Contractor)
sdtsui
Thomas Huang
frankiebee
Dan Finlay
Kevin Serrano
Dan Finlay
Zac Mitton