A bug was discovered in d17cc9fa which would raise a failure to push
into the browser's history if a base href was defined. Fix the failure
by removing react-router. Anyway, the usage of react-router was
incorrect because the app must hit the server infrastructure when it
enters a room because the server will choose the very app version then.
In preparation for and as another early step in rewriting the Web
version of jitsi-meet using React, use Haste resolver which is able to
distinguish among platform-independent files, Web-specific and
mobile-specific ones.
Additionally, (1) make sure that Babel is capable of understanding React
files and (2) introduce React as a dependency.
The purpose is to repeatedly take small steps towards our goal and merge
them before they get in conflict with the separate ongoing advancement
of the Web version of jitsi-meet.
As a step toward merging jitsi-meet-react with jitsi-meet to share as
much source code as possible between mobile and Web, merge the part of
jitsi-meet-react's source tree which supports mobile inside the
jitsi-meet source tree and leave jitsi-meet-react's Web support in the
source code revision history but don't have it in master anymore because
it's different from jitsi-meet's Web support. In other words, the two
projects are mechanically merged at the file level and don't really
share source code between mobile and Web.
React Native's module bundler (aka packager) has its default Babel
preset - react-native/babel-preset - which it uses in the absence of a
custom .babelrc. Unfortunately, the default may be tripped by the
presence of a .babelrc in dependencies. Additionally, if the default
does not get tripped, the npm install of lib-jitsi-meet as a dependency
may fall into a recursion in which Babel attempts to transpile
react-native/babel-preset. To reduce the risks of stumbling upon such
problems, move Babel's configuration inside the Webpack configuration
file.
Since the library lib-jitsi-meet does not publish its binaries, it is
always been necessary to produce the binaries i.e. lib-jitsi-meet.js and
lib-jitsi-meet.js as part of the npm install step. Which means that any
modifications to the devDependencies of lib-jitsi-meet's package.json
always have to be reflected in jitsi-meet's package.json. Because
Webpack replaced Browserify in lib-jitsi-meet, Webpack has to become a
devDependency of jitsi-meet.
Since the library lib-jitsi-meet does not publish its binaries, it is
always been necessary to produce the binaries i.e. lib-jitsi-meet.js and
lib-jitsi-meet.js as part of the npm install step. Which means that any
modifications to the devDependencies of lib-jitsi-meet's package.json
always have to be reflected in jitsi-meet's package.json. Because
Webpack replaced Browserify in lib-jitsi-meet, Webpack has to become a
devDependency of jitsi-meet.
Using "compatible version" as ^... matches latest version 1.12.0 and not 1.10.5 (matches >=1.10.5 < 2.0.0) and this prevents it building from source with latest nodejs on clean environment.