By Nicholas Zakas CHAPTER 2When large companies or organizations rely on the component, there
is more incentive for its developer to keep updating the component and
fixing bugs.
That doesn’t mean you shouldn’t deploy anything unless it’s being used
by Facebook or Google, it just means that your Web application shouldn’t
be the first to rely on that component. There is safety in numbers and the
more users of any component, the more likely it will continue to evolve
and issues will be resolved.
So make sure to keep in mind that not all jQuery plugins are the built
the same. Not all NPM modules are built the same. And certainly not all
open-source projects are built the same. Anyone can create an open-source
component but not everyone is dedicated to continuing it. Make sure to
do your due diligence on any third-party component before including it in
your product. One bad decision could create cracks in your foundation that
may be hard to fix later.
Part of your due diligence should be to look at the third-party code
itself. You need to be sure there’s nothing malicious buried inside before
deploying it. Failing to do some cursory examination of the code could lead
to trouble. In 2011, a now-defunct website disappeared from Google search
results overnight^22. After some lengthy exploration, it was determined that
a WordPress plugin was to blame. Whenever the Googlebot visited the
site, the plugin would redirect elsewhere. The person who wrote the plugin
had made a mistake in the code as he intended only to block the Googlebot
from the plugins directory (see his explanation^23 ). Unfortunately, the dam-
age was done and caused a lot of inconvenience for those using the plugin.
Intentional or not, the potential damage third-party components can
cause to your application is significant. Don’t assume that all third-party
components are made the same. Spend time investigating before including
them in your application.
22 http://smashed.by/wp-plugins-traffic
23 http://smashed.by/apologies