d1c587a01c
More spec fixes replace process.nextTick with setTimeout(fn, 0) for specs Also added an unspy in the afterEach Temporarily disable specs fix(spec): start fixing specs Summary: This is the WIP fix to our spec runner. Several tests have been completely commented out that will require substantially more work to fix. These have been added to our sprint backlog. Other tests have been fixed to update to new APIs or to deal with genuine bugs that were introduced without our knowing! The most common non-trivial change relates to observing the `NylasAPI` and `NylasAPIRequest`. We used to observe the arguments to `makeRequest`. Unfortunately `NylasAPIRequest.run` is argumentless. Instead you can do: `NylasAPIRequest.prototype.run.mostRecentCall.object.options` to get the `options` passed into the object. the `.object` property grabs the context of the spy when it was last called. Fixing these tests uncovered several concerning issues with our test runner. I spent a while tracking down why our participant-text-field-spec was failling every so often. I chose that spec because it was the first spec to likely fail, thereby requiring looking at the least number of preceding files. I tried binary searching, turning on and off, several files beforehand only to realize that the failure rate was not determined by a particular preceding test, but rather the existing and quantity of preceding tests, AND the number of console.log statements I had. There is some processor-dependent race condition going on that needs further investigation. I also discovered an issue with the file-download-spec. We were getting errors about it accessing a file, which was very suspicious given the code stubs out all fs access. This was caused due to a spec that called an async function outside ot a `waitsForPromise` block or a `waitsFor` block. The test completed, the spies were cleaned up, but the downstream async chain was still running. By the time the async chain finished the runner was already working on the next spec and the spies had been restored (causing the real fs access to run). Juan had an idea to kill the specs once one fails to prevent cascading failures. I'll implement this in the next diff update Test Plan: npm test Reviewers: juan, halla, jackie Differential Revision: https://phab.nylas.com/D3501 Disable other specs Disable more broken specs All specs turned off till passing state Use async-safe versions of spec functions Add async test spec Remove unused package code Remove canary spec |
||
|---|---|---|
| .. | ||
| assets | ||
| lib | ||
| spec | ||
| stylesheets | ||
| icon.png | ||
| package.json | ||
| README.md | ||
| screenshot.png | ||
Composer Templates
Create templates you can use to pre-fill the N1 composer - never type the same email again! Templates live in the ~/.nylas/templates directory on your computer. Each template is an HTML file - the name of the file is the name of the template, and it's contents are the default message body.
If you include HTML <code> tags in your template, you can create
regions that you can jump between and fill easily.
Give <code> tags the var class to mark them as template regions. Add
the empty class to make them dark yellow. When you send your message, <code>
tags are always stripped so the recipient never sees any highlighting.
This example is a good starting point for plugins that want to extend the composer experience.
Install this plugin
-
Download and run N1
-
From the menu, select
Developer > Install a Plugin Manually...The dialog will default to this examples directory. Just choose the package to install it!When you install packages, they're moved to
~/.nylas/packages, and N1 runsapm installon the command line to fetch dependencies listed in the package'spackage.json