Over the years, much before I started working on Frappe Books, a lot of the code that frappejs was to handle was added to the books repository. This included:
Almost all of the UI code.
Electron related code.
Build configurations
Due to this around ~60% of the frappejs repository was rendered redundant, at least in the context of Frappe Books. The main reason for Frappe JS was due to Frappe Books.
I used to push PRs to Frappe JS due to requirements arising in Frappe Books. But over time, maintaining another repo for books seemed to make less and less sense especially for 3k or so lines of code. This also caused the build to break often. And in general, keeping the two in sync was a pain.
So I decided to inline the books relevant part of frappejs code into books (PR). This means that I won't be pushing any code to frappejs from now on.
So until resolved uncertainties, no further development is going to take place on this project.
Over the years, much before I started working on Frappe Books, a lot of the code that
frappejswas to handle was added to thebooksrepository. This included:frappejsrepository was rendered redundant, at least in the context of Frappe Books. The main reason for Frappe JS was due to Frappe Books.I used to push PRs to Frappe JS due to requirements arising in Frappe Books. But over time, maintaining another repo for
booksseemed to make less and less sense especially for 3k or so lines of code. This also caused the build to break often. And in general, keeping the two in sync was a pain.So I decided to inline the
booksrelevant part offrappejscode intobooks(PR). This means that I won't be pushing any code tofrappejsfrom now on.So until resolved uncertainties, no further development is going to take place on this project.