Summary:
There are some settings that apply to dev and prod modes that we don't want
to use while benchmarking. E.g. the folder where we store messages,
whether we generate long stack traces in our bluebird promises, etc.
This diff adds a benchmark mode so that we can change these settings to
something that works better for benchmarking.
Test Plan: Run locally, verify it works
Reviewers: evan, juan, spang
Reviewed By: juan, spang
Differential Revision: https://phab.nylas.com/D4374
Summary:
build-client, aka packaging, aka bundling is now separate from uploading.
This is both to compartmentalize our tasks a bit more and so we can add a
non-grunt windows task inbetween packaging and uploading.
No more heavily-overloaded PUBLISH_BUILD flag.
Added SIGN_BUILD flag instead.
No more TRAVIS and TRAVIS_PULL_REQUEST flag.
Test Plan: Manual
Reviewers: halla, juan, spang
Reviewed By: juan, spang
Differential Revision: https://phab.nylas.com/D4208
Summary:
Implements `test-cloud` to cd into each cloud package and run `npm test`.
It's easier this way because of the relative paths in the Jasmine configs,
and this also ensures that the tests can always be run within their
individual packages too.
Also calls `test-cloud` from `test` so people don't forget about it. If
someone wants to test just the client, they can explicitly do so with
the `test-client` script.
Depends on D4058, D4059, D4061, and D4062
Test Plan: Ran the tests
Reviewers: evan, mark, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D4031
Summary:
Also see:
3a33b0ad64
which was hot-pushed to master in order to get Travis building.
We now have two travis files:
1. /.travis.yml
2. /packages/client-app/travis.yml
The first one is alwas in the private repo and runs `npm install && npm
run build-client`. This decrypts our keys and signs, builds, and uploads
to S3.
The second one is designed to live in our yet-to-be public mirror. It will
basically just run `npm install && npm test`.
That way the public one should just about ALWAYS pass (YAY!) except of
course when you break the tests or something in the installer!
Test Plan: Run on new https://travis-ci.com/nylas/nylas-mail-all
Reviewers: jerm, spang, juan
Reviewed By: spang, juan
Differential Revision: https://phab.nylas.com/D3999
Summary:
Grunt is hardcoded to use paths relative to wherever the Gruntfile is
located. Unfortunately it also expects the grunt packages to be siblings
of that gruntfile. We can get around this by changing the relative base
path, but then the cwd is different for each tasks. This is okay as long
as we use absolute paths for various files in each of our tasks. This
updates our grunt tasks to use absolute paths
Test Plan: `npm run build-client`
Reviewers: spang, halla, jerm, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3987
Summary:
It doesn't really make sense to have the root package.json have any
dependencies since it's never "packaged" or built itself. Everything
really should be a dev dependency. This was only separated before because
the Dockerfile unnecessarily added the --production flag.
This will make the docker build take a smidge longer, but I think it's
worth the extra minute to keep the dependencies orderly and sematically
correct
Test Plan: re-run docker build
Reviewers: jerm, spang, juan
Reviewed By: juan
Differential Revision: https://phab.nylas.com/D3978
Summary:
Adding READMEs for easy and helpful browsing on GitHub.
Also add missing script and `--interpreter` flag
Test Plan: Run new launch commands
Reviewers: mark, spang, juan, halla
Reviewed By: spang, juan, halla
Differential Revision: https://phab.nylas.com/D3971
[*] update babel
[client-app] remove flow-typed
[client-app] Move build/package.json to main package.json
[client-app] remove spec_integration
[client-app] fix babel support
Add client-private-plugins package.json
[client-app] add node_modules to global path for private-plugins
Move client-sync dependencies to client-app root
fix electron rebuild
[*] moved to monorepo
Summary: App now runs in monorepo
Test Plan: npm test
Reviewers: juan, mark, khamidou, halla, spang
Differential Revision: https://phab.nylas.com/D3947
Summary:
This commit rewrites the offline status notification from scratch, using
the `is-online` module (https://github.com/sindresorhus/is-online). The
react component no longer manages all of the state internally, but
rather depends on a separate OnlineStatusStore that manages the online state
for that component.
The new online status system will:
- Check online status every 30 seconds
- If status switches to offline:
- Show notification
- Recheck online status using exponential backoff
- Notification will show remaining seconds until next online status
check (like slack) (upon initial inspection this seemed to have no cpu problems.)
- If status switches to online
- Hide notification
- Revert to checking online status every 30 seconds
Depends on D3919
Test Plan: manual
Reviewers: spang, mark, evan
Reviewed By: evan
Differential Revision: https://phab.nylas.com/D3920
