Support multiple years #778
Conversation
Codecov Report
@@ Coverage Diff @@
## master #778 +/- ##
==========================================
+ Coverage 69.96% 70.52% +0.56%
==========================================
Files 116 194 +78
Lines 3815 6158 +2343
Branches 595 1010 +415
==========================================
+ Hits 2669 4343 +1674
- Misses 1132 1800 +668
- Partials 14 15 +1
Continue to review full report at Codecov.
|
zakpatterson
force-pushed
the
feature-years-monorepo
branch
from
504d8bd
to
12cb570
Compare
Add implementations for 2021
zakpatterson
force-pushed
the
feature-years-monorepo
branch
2 times, most recently
from
7893bfe
to
a7556e2
Compare
zakpatterson
force-pushed
the
feature-years-monorepo
branch
from
a7556e2
to
b9b1e73
Compare
zakpatterson
changed the title
Also factor out local forms
zakpatterson
force-pushed
the
feature-years-monorepo
branch
from
dfec6b7
to
067597f
Compare
|
filing status is invalidated when year is switched back to year with save state, resets after page refresh
|
|
Getting this error when trying to print federal 1040 forms |
Comment has been resolved by Zakwhen the state is Illinois, an error is thrown when navigating to /createpdf Browser metadata |
|
|
zakpatterson
force-pushed
the
feature-years-monorepo
branch
from
d31bbd3
to
72e1eba
Compare
I don't think the same EIC issue is showing up in prod |
|
I think I got the display of the proper EIC credit, as well as a more helpful message about no filing states.
|
|
Fixed up the IL1040 line 10b issue here for efficiency. |
Comment has been resolved by ZakError thrown when navigating to the /createpdf page and no information is inputted previously Browser metadata |
|
|
zakpatterson
force-pushed
the
feature-years-monorepo
branch
from
d16e50a
to
aebbc91
Compare
|
Should ask if fincen is required if you have a financial interest in an asset located in a foreign country is checked
|
Comment has been resolved by ZakSaved 1099-R information is incorrectly pulled into new 1099 form input Browser metadata |
zakpatterson
force-pushed
the
feature-years-monorepo
branch
from
375cc73
to
25a9e1b
Compare
|
|
|
this problem appears to be in prod as well |
|
As much as this PR has turned into a rewrite of the code, I think it's time to consider merging it so we can deal with other issues without conflicts. Let me know what you think. I'm open to cleaning it up in some way if it would help. |
That makes sense |
|
Really good QA / review work, lets gooooo 2021... |
Add form implementations for 2021
Work on 2019 form implementations is going on here: zakpatterson#91
What kind of change does this PR introduce?
After a lot of experimentation in #662, I suggest we maintain a monorepo structure.
I believe the benefits of splitting the repository will never outweigh the costs. The initial motivations of splitting the repo involved being able to release the forms implementations to NPM for potential use in other projects, and maintaining one coherent view of the forms implementations, using git to jump between years.
The first sign this was a bad idea was the need for
coreproject that the forms branches and the main repo could access. Splitting the code on tax year using git submodules means that now there's 2N+2 git modules that can potentially get out of sync, as each year requires a copy ofcore, and the main project requires a copy ofcore. This can be mitigated with scripts, but we're not getting anything for that complexity.We will still be able to release from a single directory in our source tree down the line, so I think even with a monorepo structure we can release our form implementations. Splitting is not necessary.
While having separate branches of our forms implementation would solve the second goal, it comes at considerable cost as each year's branch will continue to diverge from each other. To mitigate this we will require PRs to bring them closer together, example. Alternatively, in a single repository, we can simply diff the year directories to see how they are drifting, and adjust accordingly, which should be less cumbersome.
Anyway, the experiment on #662 was valuable and the form implementations developed there were easily copied into this project. At this point, however, I propose we just reorganize the source tree and leave a single repository.
Closes #662
Fixes #753