Our JSHint configuration is not extensive and we have excluded multiple
files from linting. Additionally, we have seen JSHint to be unable to
parse newer ECMAScript features such as the object spread operator
(proposal).

On the other hand, we have seen ESLint to beautifully work on React and
React Native source code in addition to ES2015 and later. Introduce
ESLint alongside JSHint as an intermediate step to eventually switching
from JSHint to ESLint.

As our source code does not fully follow even the JSHint rules we have,
it is very difficult to introduce ESLint with many rules. At the
beginning, introduce it with as little rules as possible. Morever,
ESLint is able to automatically fix certain rule offenders so once we
have ESLint merged we can incrementally add new rules while keeping our
commits' modification on as little subjects as possible.

We log an application log to callstats and analytics event.

removed white space
redid the hooking of the Transcribing module to JitsiConference
redid the exposing of the Transcribing module to JitsiMeetJs

Adds events for various disconnects, failures and reloads.

On Safari/IE we have to wait until the WebRTC stack is
initialized in case the plugin is being installed for
the first time.

You can call static Statistics methods which will internally handle callstats instances to send stats. Drops handlers and JitsiMeetJS references.

JitsiMeetJS#init accepts an options object in which the property
disableAudioLevels may optionally be defined and is meant to disable RTC
statistics related to audio levels. Unfortunately, the option was used
in a boolean expression which ignored the value of the option and thus
effectively rendered it unused.

While we have JitsiMeetJS defined as a global variable in Jitsi Meet, it
doesn't sound like an absolutely necessary and beautiful requirement
inside the library itself.