Added analytics + removal of logic related to native build

[bchevalier]

Changes overview

This PR consists in 2 main changes: 1 - The addition of the analytics component (previously located on game repos) 2 - The removal of the logic responsible for generating native builds

Reason for changes

1 - To ensure the uniqueness of the analytics component across all games (to unify the behavior of the analytics component across all games). To place the analytics setup in a bootstrap build that executes before the game build and enable the provision of early analytics (on build loading and execution times or user acquisition).

2 - Timestep has been stripped off native components and building for native was therefore impossible. Native build was unmaintainable due to the lack of test suite or product in development. More people need to be able to learn and modify the build process and the added logic of the native builder was an obstacle to a quick understanding of the code base.

Changes

1

• Bootstrap has been simplified as, among all the possible steps only the build loading was effective (maybe @yofreke can confirm?)
• Analytics parameters should be listed in the manifest.json of each game.
• Bootstrap now includes analytics and facebook initialization.
• Bootstrap moved to src/clientapi folder due to its interconnected logic with the src/clientapi/index.js file.
• src/clientapi/index.js file was stripped off of all the unused logic and greatly simplified.
• A build is now generated for the bootstrap (logic found in src/build/jsCompiler.js). Its shared dependencies with the game build are located in devkit_modules.chunk.js and node_thirdParty.chunk.js (these dependencies are therefore not duplicated).
• Generated index.html file now has JS dependencies in header
• fbinstant now loads before all other scripts.

2 - Straightforward removal of all the files located in src/build/targets/native as well as code logics related to the native build in other files located in the src directory.

Lead for future improvements

• Getting rid of more unnecessary logic in the build process (chrome building necessary? is the logic present insrc/clientapi/webpackGameEntrypoint.js necessary?)
• Right now several scripts are present in the header (fbinstant.3.2.js, web-app-manifest.json, devkitHeader.js devkit_modules.chunk.js node_thirdParty.chunk.js bootstrap.js), they could all be combined into a single script, more efficiently delivered over http1.
• Why are there 2 different build for common dependencies? (devkit_modules.chunk.js, node_thirdParty.chunk.js).
• Reducing the amount of dependencies in the header scripts could help provide analytics slightly earlier and translate into more insightful analytics

Related tasks

• Moving timestep into devkit-core to improve maintainability.
• Slightly refactoring asset map for optimized in game perf and easier integration of progressive loading in games

@yofreke @rogueSkib @bengarney @fairfieldt @RhettAtBlack for review

[bchevalier]

@yofreke logic relating to isLiveEdit has been removed.

[bengarney]

At a high level I really like this. Less code is less maintenance and mental overhead. I like this but want to make sure we have a smooth merge. Is this tested against the games?

[bengarney]

Oh - is package-lock.json intentionally included?

[bchevalier]

@bengarney I intentionally included it because I thought that was the purpose of package-lock.json. Should I remove it from the PR?

[bchevalier]

@bengarney This is tested against Everwing. It can be tested against other games too.

[bengarney]

I defer to @yofreke on this.

A quick pass confirming other games are OK is good. Don't need to go super deep if EW is solid.

[bchevalier]

@bengarney actually I spoke too fast, to test other games would require some refactoring of their analytics, so not so easy. The idea is that they would have some refactoring to do when adopting the new build system.

[bengarney]

How long would it take to do that? If it's less than a day of work it's probably worth it to get extra validation of these changes. If it's more we may just want to leave them on an older branch for a while.

[bchevalier]

Actually I would rather have this PR validated (even if not merged), so that I can move on and include timestep in it. It will help facilitate refactoring the games to make them compatible (because some changes might be required in both timestep and devkit-core).

[bengarney]

Let's consider this solid enough to move on. You can do add'l PRs against this PR so we can digest smaller changes as we go along.