Declared packages side effect free and fixed existing side effects

[maclockard]

This sets the package.json field sideEffects to false. This allows for better tree shaking by downstream consumers, see https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free for more information.

I skimmed over all included files and I did not see anything that would count following webpack's definition of tree shaking other than the line in debounce.js I fixed.

[atomiks]

I don't think there's anything to treeshake in Popper v1. Every piece of code is used/depended upon with the default import with the way the architecture is setup? @FezVrasta

In terms of bite savings, I was able to save about 0.5 kb with the following, which isn't related to treeshaking:

• Remove all code support for IE10 (only support IE11) - this is breaking even tho IE10 is long dead :/
• Remove console.log deprecation messages (or move to DEV-only messaging) - the messages probably don't matter at this point with how old the changes are now
• Set timeoutDuration to a constant 1 without that check seen in your commit (is the original code even necessary? I'm not sure I see its purpose since timeouts are about 4ms minimum in most browsers iirc)

[maclockard]

This not only affects the tree shakability of this package but also all other packages that consume popper.js.

Take the case of a package P consuming popper.js that has two exports, A and B. A makes use of popper.js but B does not. If a further downstream application only imports B from package P, webpack will not be able to tree shake out popper.js unless it is declared side effect free.

The reason being is if webpack does not know whether or not popper.js has side effects on import it cannot 'shake' the import. If it is not declared, webpack has no way of knowing if popper.js polyfills something or if it modifies the global scope in someway that B implicitly relies on.

[atomiks]

Makes sense, didn't consider that scenario