various
/
Nativefier
mirror of https://github.com/jiahaog/Nativefier
1
0
Fork 0
Code Issues Releases Wiki Activity

development.md: expand on why I'm such a bore with limiting extra deps

This commit is contained in:
Ronan Jouchet 2021-05-02 18:29:05 -04:00
parent d9670d6bb0
commit beae6e872b
1 changed files with 17 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
docs/development.md
View File

@ -5,20 +5,28 @@ need to know to get started hacking on Nativefier.
## Guidelines ## Guidelines
1. Before starting work on a huge change, gauge the interest 1. **Before starting work on a huge change, gauge the interest**
of community & maintainers through a GitHub issue. of community & maintainers through a GitHub issue.
For big changes, create a [RFC](https://en.wikipedia.org/wiki/Request_for_Comments) For big changes, create a **[RFC](https://en.wikipedia.org/wiki/Request_for_Comments)**
issue to enable a good peer review. issue to enable a good peer review.
2. Do your best to avoid adding new Nativefier command-line options. 2. Do your best to **avoid adding new Nativefier command-line options**.
If a new option is inevitable for what you want to do, sure, If a new option is inevitable for what you want to do, sure,
but as much as possible try to see if you change works without. but as much as possible try to see if you change works without.
Nativefier already has a ton of them, making it hard to use. Nativefier already has a ton of them, making it hard to use.
3. Avoid or limit adding npm dependencies. 3. **Avoid adding npm dependencies**. Each new dep is a complexity & security liability.
Each new dependency is a complexity & security liability. You might be thinking your extra dep is _"just a little extra dep"_, and maybe
4. Use types, avoid `any`, write tests. In that order. you found one that is high-quality & dependency-less. Still, it's an extra dep,
5. Document for users in API.md and over the life of Nativefier we requested changes to *dozens* of PRs to avoid
6. Document for other devs in comments, jsdoc, commits, PRs. "just a little extra dep". Without this constant attention, Nativefier would be
Say *why* more than *what*, the *what* is your code! more bloated, less stable for users, more annoying to maintainers. Now, don't go
rewriting zlib if you need a zlib dep, for sure use a dep. But if you can write a
little helper function saving us a dep for a mundane task, go for the helper :) .
Also, an in-tree helper will always be less complex than a dep, as inherently
more tailored to our use case, and less complexity is good.
4. Use **types**, avoid `any`, write **tests**.
5. **Document for users** in `API.md`
6. **Document for other devs** in comments, jsdoc, commits, PRs.
Say _why_ more than _what_, the _what_ is your code!
## Setup ## Setup