mirror of
https://github.com/Foundry376/Mailspring.git
synced 2024-09-23 00:36:50 +08:00
be4b0d773c
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 |
||
---|---|---|
.. | ||
images | ||
spec | ||
src | ||
stylesheets | ||
main.es6 | ||
package.json | ||
README.md |
Client Sync
This is the mail sync engine that runs within the Nylas Mail client
It is symlinked in as an internal_package
of Nylas Mail via the postinstall
script of the root repo.
Important Usage Notes:
Since this is symlinked in as an internal_package
of Nylas Mail, there are a
handulf of considerations when developing in client-sync. Some common gotchas:
- You MAY use
NylasEnv
,NylasExports
and other injected libraries in the Nylas Mail client environment. - You MAY use any 3rd party library declared in
client-app/package.json
. Since this gets added as a plugin of the Nylas Mail client, you'll have access to all libraries. This works because theclient-app/node_modules
was added to the global require paths. That lets us access client-app plugins without being a file directory decendent of client-app (client-sync is now a sibling of client-app) - You may NOT add "dependencies" to the
client-sync/package.json
. If you need a 3rd party library, add it to the mainclient-app/package.json
. All Nylas Mail plugins (those inside ofinternal_packages
), may no longer declare their own dependencies. - You should be aggressive at moving generic mail methods to
isomorphic-core
. We may eventually want to make large chunks of client-sync work in a cloud environment as well.