Fix DOM Event lint global false positive and access all window props explicitely

[tchakabam]

This PR will...

Acknowledged the issue that was addressed here: #1755 ...

• Fix a few false positives of linter browser-env globals for Event, which is supposed to be our event enum, but linter thought was the DOM Event constructor.

• For code safety measure, remove all preset and custom globals from our eslint config

• Only access window globals explicitely everyhwere (yes), since this is the only way to write (almost) safe code in the end

• Add a lint:quiet script to only show fatal errors in eslint output

• Mask the window global explicitely with self for transparent use of that scope in modules that are imported by both worker and main threads.

Why is this Pull Request needed?

Are there any points in the code the reviewer needs to double check?

Resolves issues:

Event not defined in decryptor and adts demuxer, which was causing error events not to be triggered in effect.

Checklist

• changes have been done against master branch, and PR does not conflict
• no commits have been done in dist folder (we will take care of updating it)
• new unit / functional tests have been added (whenever applicable)
• API or design changes are documented in API.md

[tchakabam]

Thanks for the specific fix in #1755 to alert about this general problem.

[tchakabam]

Seems like the check for Node require is breaking this.

[tchakabam]

latest commit should fix node require, but needs to be used everywhere where we need window

[tchakabam]

@johnBartos @tjenkinson

• Fixing missing Event import in decryptor.js + making all access to window/worker scopes explicit (removing all "globals" from linter config).

• Removing support for Node.js require. See discussion in relevant PR.

[tjenkinson]

@tchakabam it might also be possible to inject the window replacement with the webpack imports loader automatically https://github.com/webpack-contrib/imports-loader

[tjenkinson]

Actually if we are not supporting node why do we need to use 'self'?

[tchakabam]

@tjenkinson For workers. As explained in the PR description.

[tchakabam]

@tjenkinson If you see a use-case for injecting an own window or worker-global-scope implementation, go for it :)

[tchakabam]

Interesting webpack plugin btw ;)

[tjenkinson]

@tchakabam had a go here #1769