Mailspring/app/script/mkrpm

31 lines
765 B
Text
Raw Normal View History

fix(drafts): Various improvements and fixes to drafts, draft state management Summary: This diff contains a few major changes: 1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario: - View thread with draft, edit draft - Move to another thread - Move back to thread with draft - Move to another thread. Notice that one or more messages from thread with draft are still there. There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great. 2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here: - In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI. - Previously, when you added a contact to To/CC/BCC, this happened: <input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state. To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source! This diff includes a few minor fixes as well: 1. Draft.state is gone—use Message.object = draft instead 2. String model attributes should never be null 3. Pre-send checks that can cancel draft send 4. Put the entire curl history and task queue into feedback reports 5. Cache localIds for extra speed 6. Move us up to latest React Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
#!/bin/bash
set -e
build(*): electron-compile, electron-packager instead of custom tooling Summary: This diff removes significant cruft from N1's compilation and build tooling: - Electron-Packager replaces most of the code in build/tasks/* used to copy things, bundle things, download electron, etc. - script/bootstrap has been replaced with a much simpler script that does not use APM, does not download Electron (we just use electron as an NPM dep) and does not manully compile sqlite. It requires NPMv3, but I think that's safe. - babel and eslint are now devDependencies of the main project. The main project also supports optionalDependencies now. - npm test and npm start replace ./N1.sh - APM is still around, and is only put into N1 so it can install plugins at runtime. It should be removed as soon as we notify package maintainers and have them provide zips. - N1 no longer has it's own compile-cache or babel/typescript/coffeescript compilers. It delegates to electron-compile and electron-compilers. Both of these packages had to be forked and modified slightly, but I'm hopeful the modifications will make it back in to the projects and you can still consult their documentation for more info. + In the near future, I think we should stop shipping electron-compilers with N1. This would mean that all plugins would need to be compiled on pre-publish, just like NPM packages, and would complicate the local development story a bit, but would make the app smaller. electron-compile is not supposed to compile at runtime in the prod app, just pull from the compile cache. - I've re-organized Grunt according to Grunt best practices, where each tasks/* file specifies it's own config and imports grunt tasks. - Unfortunately, I was not able to use any open source projects for the deb and rpm builds, because we have things like postinst hooks and start menu items which are not supported by the electron installer-generators. WIP Turn off all LESS compilation, because themes. Doh. Use Grunt for new build process too, just remove tasks More changes Add babel-eslint Remove unused react-devtools WIP Add name Ignore nonexistent Switch to more modern approach to config for grunt Move zipping to mac installer task Restructure publish task so it aggregates first, can log useful info if publishing is disabled Fix build dirs Fix win installer Fix linux installer Fix linux installer Try making linux A few more Updates Upadtes fixes fixes Get rid of non-meaningful variables Resolve assets path Insert nylas.sh Clean up args more Actually use description Fix display name ugh More tweaks Expliclty write /usr/bin/nylas Improve vars Use old nylas.sh Reinstate APM to better scope this diff Test Plan: Test on Mac, Windows, Linux Reviewers: evan, jackie, juan Reviewed By: jackie, juan Differential Revision: https://phab.nylas.com/D3411
2016-11-10 05:50:46 +08:00
BUILD_DIRECTORY="$1"
APP_CONTENTS_DIRECTORY="$2"
LINUX_ASSETS_DIRECTORY="$3"
fix(drafts): Various improvements and fixes to drafts, draft state management Summary: This diff contains a few major changes: 1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario: - View thread with draft, edit draft - Move to another thread - Move back to thread with draft - Move to another thread. Notice that one or more messages from thread with draft are still there. There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great. 2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here: - In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI. - Previously, when you added a contact to To/CC/BCC, this happened: <input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state. To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source! This diff includes a few minor fixes as well: 1. Draft.state is gone—use Message.object = draft instead 2. String model attributes should never be null 3. Pre-send checks that can cancel draft send 4. Put the entire curl history and task queue into feedback reports 5. Cache localIds for extra speed 6. Move us up to latest React Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
RPM_BUILD_ROOT=~/rpmbuild
ARCH=`uname -m`
# Work around for `uname -m` returning i686 when rpmbuild uses i386 instead
if [ "$ARCH" = "i686" ]; then
ARCH="i386"
fi
# rpmdev-setuptree
mkdir -p $RPM_BUILD_ROOT/BUILD
mkdir -p $RPM_BUILD_ROOT/SPECS
mkdir -p $RPM_BUILD_ROOT/RPMS
fix(drafts): Various improvements and fixes to drafts, draft state management Summary: This diff contains a few major changes: 1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario: - View thread with draft, edit draft - Move to another thread - Move back to thread with draft - Move to another thread. Notice that one or more messages from thread with draft are still there. There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great. 2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here: - In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI. - Previously, when you added a contact to To/CC/BCC, this happened: <input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state. To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source! This diff includes a few minor fixes as well: 1. Draft.state is gone—use Message.object = draft instead 2. String model attributes should never be null 3. Pre-send checks that can cancel draft send 4. Put the entire curl history and task queue into feedback reports 5. Cache localIds for extra speed 6. Move us up to latest React Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
build(*): electron-compile, electron-packager instead of custom tooling Summary: This diff removes significant cruft from N1's compilation and build tooling: - Electron-Packager replaces most of the code in build/tasks/* used to copy things, bundle things, download electron, etc. - script/bootstrap has been replaced with a much simpler script that does not use APM, does not download Electron (we just use electron as an NPM dep) and does not manully compile sqlite. It requires NPMv3, but I think that's safe. - babel and eslint are now devDependencies of the main project. The main project also supports optionalDependencies now. - npm test and npm start replace ./N1.sh - APM is still around, and is only put into N1 so it can install plugins at runtime. It should be removed as soon as we notify package maintainers and have them provide zips. - N1 no longer has it's own compile-cache or babel/typescript/coffeescript compilers. It delegates to electron-compile and electron-compilers. Both of these packages had to be forked and modified slightly, but I'm hopeful the modifications will make it back in to the projects and you can still consult their documentation for more info. + In the near future, I think we should stop shipping electron-compilers with N1. This would mean that all plugins would need to be compiled on pre-publish, just like NPM packages, and would complicate the local development story a bit, but would make the app smaller. electron-compile is not supposed to compile at runtime in the prod app, just pull from the compile cache. - I've re-organized Grunt according to Grunt best practices, where each tasks/* file specifies it's own config and imports grunt tasks. - Unfortunately, I was not able to use any open source projects for the deb and rpm builds, because we have things like postinst hooks and start menu items which are not supported by the electron installer-generators. WIP Turn off all LESS compilation, because themes. Doh. Use Grunt for new build process too, just remove tasks More changes Add babel-eslint Remove unused react-devtools WIP Add name Ignore nonexistent Switch to more modern approach to config for grunt Move zipping to mac installer task Restructure publish task so it aggregates first, can log useful info if publishing is disabled Fix build dirs Fix win installer Fix linux installer Fix linux installer Try making linux A few more Updates Upadtes fixes fixes Get rid of non-meaningful variables Resolve assets path Insert nylas.sh Clean up args more Actually use description Fix display name ugh More tweaks Expliclty write /usr/bin/nylas Improve vars Use old nylas.sh Reinstate APM to better scope this diff Test Plan: Test on Mac, Windows, Linux Reviewers: evan, jackie, juan Reviewed By: jackie, juan Differential Revision: https://phab.nylas.com/D3411
2016-11-10 05:50:46 +08:00
cp -r "$APP_CONTENTS_DIRECTORY/"* "$RPM_BUILD_ROOT/BUILD"
cp -r "$LINUX_ASSETS_DIRECTORY/icons" "$RPM_BUILD_ROOT/BUILD"
cp "$BUILD_DIRECTORY/mailspring.spec" "$RPM_BUILD_ROOT/SPECS"
cp "$BUILD_DIRECTORY/mailspring.desktop" "$RPM_BUILD_ROOT/BUILD"
fix(drafts): Various improvements and fixes to drafts, draft state management Summary: This diff contains a few major changes: 1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario: - View thread with draft, edit draft - Move to another thread - Move back to thread with draft - Move to another thread. Notice that one or more messages from thread with draft are still there. There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great. 2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here: - In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI. - Previously, when you added a contact to To/CC/BCC, this happened: <input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state. To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source! This diff includes a few minor fixes as well: 1. Draft.state is gone—use Message.object = draft instead 2. String model attributes should never be null 3. Pre-send checks that can cancel draft send 4. Put the entire curl history and task queue into feedback reports 5. Cache localIds for extra speed 6. Move us up to latest React Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
rpmbuild -ba "$BUILD_DIRECTORY/mailspring.spec"
cp $RPM_BUILD_ROOT/RPMS/$ARCH/mailspring-*.rpm "$BUILD_DIRECTORY"
fix(drafts): Various improvements and fixes to drafts, draft state management Summary: This diff contains a few major changes: 1. Scribe is no longer used for the text editor. It's just a plain contenteditable region. The toolbar items (bold, italic, underline) still work. Scribe was causing React inconcistency issues in the following scenario: - View thread with draft, edit draft - Move to another thread - Move back to thread with draft - Move to another thread. Notice that one or more messages from thread with draft are still there. There may be a way to fix this, but I tried for hours and there are Github Issues open on it's repository asking for React compatibility, so it may be fixed soon. For now contenteditable is working great. 2. Action.saveDraft() is no longer debounced in the DraftStore. Instead, firing that action causes the save to happen immediately, and the DraftStoreProxy has a new "DraftChangeSet" class which is responsbile for batching saves as the user interacts with the ComposerView. There are a couple big wins here: - In the future, we may want to be able to call Action.saveDraft() in other situations and it should behave like a normal action. We may also want to expose the DraftStoreProxy as an easy way of backing interactive draft UI. - Previously, when you added a contact to To/CC/BCC, this happened: <input> -> Action.saveDraft -> (delay!!) -> Database -> DraftStore -> DraftStoreProxy -> View Updates Increasing the delay to something reasonable like 200msec meant there was 200msec of lag before you saw the new view state. To fix this, I created a new class called DraftChangeSet which is responsible for accumulating changes as they're made and firing Action.saveDraft. "Adding" a change to the change set also causes the Draft provided by the DraftStoreProxy to change immediately (the changes are a temporary layer on top of the database object). This means no delay while changes are being applied. There's a better explanation in the source! This diff includes a few minor fixes as well: 1. Draft.state is gone—use Message.object = draft instead 2. String model attributes should never be null 3. Pre-send checks that can cancel draft send 4. Put the entire curl history and task queue into feedback reports 5. Cache localIds for extra speed 6. Move us up to latest React Test Plan: No new tests - once we lock down this new design I'll write tests for the DraftChangeSet Reviewers: evan Reviewed By: evan Differential Revision: https://review.inboxapp.com/D1125
2015-02-04 08:24:31 +08:00
rm -rf "$RPM_BUILD_ROOT"