Quite normal when dealing with "packages" as you basically leave yourself at the whims and mercy of others. You have no guarantee when you blindly include something someone threw up on NPM or the web that it will be maintained in the future and YES, it will often fall upon you to fork and manage your own version.
Also plays to why I prefer to LOOK at the code of these types of softwares and then write my own parallel implementation should the codebase not be up to snuff. TOO MANY PEOPLE use "don't reinvent the wheel" as a lame excuse for blindly trusting others, or to cover up for not being qualified to do a damned thing on their own.
My typical smarmy response being "What if someone has said that to Ed Michelen or Jon Dunlop?" -- we'd still be riding around in carriages that use steel hoops heat-shrunk onto wooden rims.
I mean you even just poke your head into the project and come across gems of ineptitude like making copies of variables for no reason, creating variables before a short-circuit return would even allow them to be used for anything, a seeming fear of even using ternary operators for the simplest of tasks, if/else where case would be more efficient and easier to maintain -- You should be running in a panic to rewrite it before you even consider adding it to your project!
See gems like this:
if (styleMatch) {
value = value.replace(styleMatch[0], 'style-src \'nonce-' + res.locals.nonce + '\'');
}
else {
value = value.replace('style-src', 'style-src \'nonce-' + res.locals.nonce + '\'');
}
Such strange inefficiencies and code bloat are rampant across every file I look at in that -- though it's doing SO MUCH string replacement that's troublesome too. Hell, the sheer volume of stuff it slops into the global scope alone raises the hackles on my hackles... sadly too common though when codebases that aren't large enough to be one single file end up broken into dozens in the name of "modularity" without bothering to hook the extensible nature of JS objects.
Jason Knight
The less code you use, the less there is to break
Quite normal when dealing with "packages" as you basically leave yourself at the whims and mercy of others. You have no guarantee when you blindly include something someone threw up on NPM or the web that it will be maintained in the future and YES, it will often fall upon you to fork and manage your own version.
Also plays to why I prefer to LOOK at the code of these types of softwares and then write my own parallel implementation should the codebase not be up to snuff. TOO MANY PEOPLE use "don't reinvent the wheel" as a lame excuse for blindly trusting others, or to cover up for not being qualified to do a damned thing on their own.
My typical smarmy response being "What if someone has said that to Ed Michelen or Jon Dunlop?" -- we'd still be riding around in carriages that use steel hoops heat-shrunk onto wooden rims.
I mean you even just poke your head into the project and come across gems of ineptitude like making copies of variables for no reason, creating variables before a short-circuit return would even allow them to be used for anything, a seeming fear of even using ternary operators for the simplest of tasks, if/else where case would be more efficient and easier to maintain -- You should be running in a panic to rewrite it before you even consider adding it to your project!
See gems like this:
if (styleMatch) { value = value.replace(styleMatch[0], 'style-src \'nonce-' + res.locals.nonce + '\''); } else { value = value.replace('style-src', 'style-src \'nonce-' + res.locals.nonce + '\''); }Doing the job of:
value = value.replace( styleMatch ? styleMatch[0] : 'style-src', "style-src 'nonce-" + res.locals.nonse + "'" );Such strange inefficiencies and code bloat are rampant across every file I look at in that -- though it's doing SO MUCH string replacement that's troublesome too. Hell, the sheer volume of stuff it slops into the global scope alone raises the hackles on my hackles... sadly too common though when codebases that aren't large enough to be one single file end up broken into dozens in the name of "modularity" without bothering to hook the extensible nature of JS objects.