When yarn started, it really was a performance improvement over npm at the time... but npm has gotten (much) better... I think it's just best to generally stick with npm, though the past couple jobs I've been at they were using yarn.
The debounce answer isn't quite right... the timeout should be from the first call, it should hold a map against the callback method, and expressly not reset the timer... the debounce should (generally) be from the first call, not the most recent call. Although there are times you may want that kind of debounce, that's not how most libraries implement it.
The following question often tells me how well a developer actually understands JavaScript as a language.
What specific values are falsy in JavaScript?
Although that isn't the only question, most of the questions in TFA are really generic and most devs with any formal training can answer them.
I took a very similar approach when I made my first Node API over a decade ago. In the end, it got complicated pretty quickly. I actually really like the Koa/Oak approach myself.
When you get to the point of even several dozen routes, I can imagine the registration methods in TFA to become overly cumbersome to say the least.
Just my own $.02 on this.
Worth noting, that adding a month the naive way won't always get you what you should expect... for example:
let dtm = new Date(2020,0,31); // Fri Jan 31 2020...
dtm.setMonth(dtm.getMonth() + 1);
console.log(dtm);
// Mon Mar 02 2020...
That's not what you should expect, I would expect the last day of February.
function addMonths(dtm, months = 1) {
const month = dtm.getMonth() + ~~months;
const ret = new Date(dtm); // clone date - don't mutate
ret.setMonth(month);
if (ret.getMonth() > month) {
ret.setDate(0); // go to end of previous month
}
return ret;
}
This way you can add to the date, without mutation and get the expected result.
let dtmIn = new Date(2020,0,31);
let dtmOut = addMonths(new Date(2020,0,31));
console.log(dtmOut);
// Sat Feb 29 2020...