Multi-line `if`/`for` statements in JS can be confusing since there
aren’t braces to indicate which code is enclosed in the statement. I set
the configuration to `multi-line` to enforce usage of braces for
multi-line statement bodies, but still allow things like `if (foo)
return;`. I additionally added the `consistent` option to require braces
for all elements of an if/else chain if one element has it. As you can
see, this set of options pretty closely matches the existing code style.

I was going to comment in #1008 about this stylistic change but realized
that it’s (IMO) a little impolite to ask for code style changes unless
they can be automatically enforced.

Note that `if (foo) { \n return; \n }` is still valid and won’t be
collapsed. I tried to automatically collapse all such cases but it was a
lot of files and I didn’t want to pick out the useful from the useless
differences.

Closes #996

Closes #375

Closes #943

Creates the transaction when clicking "enter". Irrelevant of which field
is currently active.

Fixes #615. I would appreciate double-checking that I didn’t
accidentally delete anything that is important.

Since I’m removing the related API methods, this is technically a
breaking change (even if people would have no reason to remove this
stuff), so we should probably do a major release of the API package.

This attempts to add priorities for goal templates and addresses most of
https://github.com/actualbudget/actual/issues/959

.

I couldn't find a good way to preserve both "Apply" and "Overwrite"
operations, so this PR does away with the current "Apply" action
behavior. Every box with a budgeted value will be overwritten if a
template goal is present.

The added syntax to define priorities is as follows:
#template    -- priority 0, highest priority
#template-1  --priority 1, 2nd highest priority
#template-2 --priority 2, 3rd highest priority
#template-N --priority N, as many as you'd like.

~~Leaving as a draft as this may not be the preferred implementation but
I wanted others to be able to try it with netlify.~~

---------

Co-authored-by: Caleb Young <cwy@rincon.com>

Improving error handling for Nordigen.

Before: if loading banks failed - a loading indicator would be shown
forever.

After: is loading banks fails - an error message is shown.

Removing unused `prop-types` dependency.

Switch to TS version of `no-unused-vars` rule. 

This is the last PR with lots of renaming for `loot-core`!

Closes #956

Closes #965

Closes #935

Before: we render all the pages (even the inactive ones in some cases)

After: we render only the visible pages. Thus the topbar color is set
only 1x.. thus the settings page topbar has the correct color.

Closes #551

Make scheduled transfers appear in both accounts.

<!-- Thank you for submitting a pull request! Make sure to follow the
instructions to write release notes for your PR — it should only take a
minute or two:
https://github.com/actualbudget/docs#writing-good-release-notes -->

Resolves issue #844 .

---------

Co-authored-by: biohzrddd <>

Closes #927

Upgrading `Downshift` dependency

Another batch of `loot-core` migrated.

Hi there, `Peg.js` is unmaintained, so I figure you all would appreciate
if I replaced it with the drop-in replacement of Peggy. This is work I
am breaking out of #918.

Peggy adds new features like source map support that we could use,
although I do not include that in this change-set. It may be useful for
debugging changes to the .pegjs file we have.e

Hi there, 

I try to tackle #798 here. It was suggested to throw this behind a
feature flag, so here it is!

this does its best to import the problem file in #767. 

I am working on this because it would make my work on #918 easier :)

Feel free to set the feature flag to true and try the new importer. The
date parser is not as sophisticated as the one in `node-libofx`, but I
tried 3 different OFX files, one from my bank, one from the mocks, and
one from #767. They all seem to work well enough on that front, but this
is definitely the weak point of the new implementation.

Let me know what you think!

This is an initial concept for adding percent based goal targets.

This version works by using a string in the form of: 
#template 10% of Income <- Income is an income category name. Only
income category names will work here currently.
or
#template 10% of all income<- 'all income' is a keyword in this context
and will base the calculation on the total income for the month.

Some of the nicer touches like Jed's polite notification that the syntax
isn't correct is not implemented here yet.