feature/scaffold_electron_boilerplate

[abdigali1]

closes #12

Research recap:

We used electron-forge because, as Yerke said, it has build-in package and tools for creating, building the Electron apps. Also electron forge has templates, in our situation I used "webpack+typescript" template (also has just a webpack and just a typescript templates).
Webpack added, typescript added, connection, dependencies between them already added and last thing we need is React. In order to add it, I read https://ankitbko.github.io/2019/08/electron-forge-with-react-and-typescript/ article (I mentioned in #12), where you just need to install React packages, add div with root id in index.html, add App.tsx file, where you should code. Change .tsconfig file, to know that you will use react jsx and entryPoint in package.json, that your entryPoint will be App.tsx.

[nugmanoff]

Change to appropriate project name.

[nugmanoff]

According to Semantic Versioning, applications in the phase of first development release are better versioned as "0.1.0". Because "1.0.0" usually refers to stable production release.

[nugmanoff]

I am not really sure about this vs Babel
I think that Babel is in general more reliable, extensible & configurable. If we will opt for Babel - here we will have some dev command that would run watchman & tsc typecheck.

I think that slow builds are not such of a big deal for us - because our project is quite small, and this kind of thing looks quite premature to me. As Donald Knuth famously put it once:

Premature optimization is the root of all evil

[nugmanoff]

I understand that this versions are set by the electron-forge template you used and nothing is wrong with it - I checked their releases tab, seems that they have been developing in -beta.x for quite long now.

But for the future projects, keep in my mind that using any beta, alpha, rc - version is quite dangerous, especially due to the amount of third-party dependencies usually used in npm-based projects.

[nugmanoff]

FYI:
Also you should mindfully use version specifiers ^1.x.x, ~1.x.x. and *1.x.x.
It is really important to have tight control on your third-party dependency. Because +1 third-party dependency is -1 to stability of your system.

It is obvious - you rely on code of "some other" developers and you trust it blindly. But if one day they will break the reverse compatibility or just anything inside of their modules - your app most likely is going to crash in production and most probably it will cost your company some money.

So be aware of proper usage of version specifiers, mostly people don't care about them, but it is better to have some "insurance" beforehand.

[nugmanoff]

Also please read my comment on Mura's PR, where I wrote about branch naming.

[nugmanoff]

Note that your commit is not associated with your GitHub (you can see that by looking at commit). You can fix it by specifying git config username.

P.S. Also if you are interested check about signing commits - it is a nice practice overall to sign your commits with GPG.

[nugmanoff]

I read through articles that you have provided - and I think it is better to use Babel for the following reasons:

• It is more reliable (fork-ts-checker is nice, but it is yet poor 900 stars, doesn't look so promising as of now)
• It is more universal and conventional
• Less error-prone (if we will encounter some issues with fork-ts-checker - God help us :)
• Main point against Babel is that it takes too long for builds to finish, but as I said it is kind of premature optimization I think. And as the author stated in this article, we can speed things up by running type-check as a separate command (e.g. yarn test).

[nugmanoff]

Please check that we can use Hot Reloading (HMR) while developing our app, if you don't know what it is look it up. And try to enable it in our project as well.

[nugmanoff]

Also please sync with Nartay on #3 because these two tasks are related.

[nugmanoff]

All in all, you did very well!
I really liked your thorough research and comparison that you did in #12
Good job, brother! Keep it up 🚀 💪

[abdigali1]

I fixed everything apart of some HMR.
I tried to setup a react-hot-reload, but everytime I stuck at one problem.
I tried electron electron-reload, but it doesn't work with webpack, as I understood PR for that
Tried electron-reloader, electron-hot-loader (doesn't work with ts, tsx) and some other stuff and still do not find suitable one.
Added babel and possibility to check types, using "npm run check-types" or, if you want watch file, during development, use "npm run check-types -- --watch"