Feature: More than 1 set of entry points

[Jaid]

Browser extension projects can grow pretty fast and developers might want to split the codebase in more than 2 entry points for sake of maintainability.

One of my project's manifest.json looks like this:

{
    "manifest_version": 2,
    "options_page": "options.html",
    "background": {
        "page": "background.html"
    },
    "browser_action": {
        "default_popup": "popup.html"
    },
    "content_scripts": [
        {
            "matches": ["*://www.website.com/profile/*.html"],
            "css": ["content_scripts/css/profile.css"],
            "js": ["content_scripts/profile.js"]
        },
        {
            "matches": ["*://www.website.com/start/*.html"],
            "css": ["content_scripts/css/homepage.css"],
            "js": ["content_scripts/homepage.js"]
        }
    ],
    "content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'"
}

webpack.config.js

config.entry = {
    "content_scripts/profile": "./src/content_scripts/profile.jsx",
    "content_scripts/homepage": "./src/content_scripts/homepage.jsx",
    "background": "./src/background.jsx",
    "options": "./src/options.jsx",
    "popup": "./src/popup.jsx"
}

Two big sections of the target site "website.com" are handled by two different content scripts. There is currently no way (at least I didn't find any) to make webpack-chrome-extension-reloader reload changes for both content script entries.

I would like to make webpack-chrome-extension-reloader listen to changes of background, content_scripts/profile and content_scripts/homepage.

I will create a pull request based on this feature request.

[rubenspgcavalcante]

So, the best way to do this keeping the retrocompatibility is make the entry accept a config object or a array of it.

declare type PluginOptions = { port: number, reloadPage: boolean, entries: EntriesOption | EntriesOption[]};
declare type EntriesOption = { background: string, contentScript: string };

I closed your last PR, but you're free to make the modifications and do another PR, or I can take and work on it (just say) :)

Thanks!

[Jaid]

The approach from pull request #37 would make an options object look like this:

new ChromeExtensionReloader({
    entries: {
        contentScript: "content_scripts/homepage",
        background: "background",
        extra: ["content_scripts/profile"]
    }
})

I didn't think that could break any compatibility, since entries.extra is optional and just adds more checks to src/utils/middleware-injector.ts.

What would an option object look like following your suggested approach? Like this?

new ChromeExtensionReloader({
    entries: [{
        contentScript: "content_scripts/homepage",
        background: "background"
    }, {
        contentScript: "content_scripts/profile",
        background: "background"
    }]
})

Every EntriesOption currently requires a background and a contentScript. Would that mean that I have to list my background entry twice in the plugin options?

We could make entries[].background and entries[].contentScript optional. But there could be a technical requirement for both of them that I am not aware of.

[rubenspgcavalcante]

Yes, my bad, actually what I mean was:

declare type EntriesOption = { background: string, contentScript: string | string[] };

So you can pass one or more entries in contentScript option.
This way, we do similar to what webpack does when you declare an entry, which can be a path to a file or multiple paths inside an array. Other point is avoiding adding more configuration options and staying concise for the plugin users (why I can set one entry there, and multiple in extras? Which order should I do that?)

Anyway, I'll try to get some free time and work on this 👍

[Jaid]

I just had in mind that (even though I only need them for additional content script entries) other developers may have to deal with Webpack entry points we are currently not aware of, but whose changes should also trigger an extension reload (options.js or popup.js or something completely different), so I wanted to keep the option for additional entry names as general as possible.

But that was just based on the thought of what other developers could need in the future. I am already happy with options.contentScript being string | string[] and look forward to your incoming changes. Thank you. :)

[gurkerl83]

Hi, any chance PR#38 is stable and can be delivered with the next version? Thanks!

[rubenspgcavalcante]

I've reviewed and asked some changes on the opened PR, but he's taking to long to respond.
Anyway, the changes are small, if he doesn't give some feedback soon I'll do the changes and release a new minor version. 👍

[rubenspgcavalcante]

Ok, released on the new version 0.8.0 👍