Refactoring chrome-extension.js

[alexstrat]

chrome-extension.js is a big, but ugly, file that holds big parts of logic. If we want to make the lib more easy to work on, we should refactor this file.

chrome-extension.js expose 2 public APIs:

• addExtension(extensionId, srcDirectory)
• removeExtension(extensionId)

addExtension is responsible for:

• reading and interpreting manifest.json
• starting background pages
• instantiating API handlers via (fairly recent) ChromeAPIHandler for storage, webRequest, windows
• defining some API handlers (legacy, to be moved to ChromeAPIHandler) for runtime, tabs, web navigation (others ?)
• doing content scrips injection
• doing content-security injection (?): seems very hacky
• load devtools extension: hacky, needs to be done via support of chrome.devtools APIs
• (outside chrome-extension.js): serve chrome-extension://* in engine/protocol

These responsibilities could be split into several modules.

[alexstrat]

// responsible to provide assets (files, manifest..) of a given extension
interface ExtensionAssetsProvider {
  extensionId: string
  asycn getManifest: () => object
  // readfile('main.html') will find `main.html` in extension folder
  readFile: (relativePath) => {mimeType: string, data: Stream }
}

interface BackgroundPagesManager() {
  start(extensionId: string, extensionsAssets: ExtensionAssetsProvider): BackgroundPage,
  stop(extensionId: string)
}

interface ContentScriptsInjector() {
  addContentScriptsForExtension(extensionId: string, extensionsAssets: ExtensionAssetsProvider)
  removeContentScriptsForExtension(extensionId: string)
}

[alexstrat]

Moreover, in ChromeAPIHandler, I think we should abstract the use of IPC to ease the unit-tesing.

A candidate for this: https://github.com/JsCommunity/json-rpc-peer that can use streams of JSON-RPC