How would this work for content scripts?

[kokjinsam]

Thank you for boilerplate! I'm currently working on a Chrome extension that needs content scripts. So far I have been able to get it working by proxying to iFrame. That's not ideal. How would you go about making content scripts work?

[samuelsimoes]

I hadn't thought about this. I'll search and propose some elegant way to do this with this boilerplate.

[samuelsimoes]

Hi. I made some changes on the boilerplate.

Now, all files will be written on the dist folder, but we still using the webpack dev server, hot reload and all these cool things. With this change, now you can make reference on your manifest to files on your build folder, so, if you want to create a content script called foo, you should put on your Chrome manifest:

"content_scripts": [
  {
    "matches": ["http://www.google.com/*"],
    "js": ["foo.js"]
  }
]

and declare that this file shouldn't be hot reloaded because you won't get the connection with the webpack dev server socket in other domain. To do so, just declare on your webpack.config.js the excludeEntriesToHotReload option. Like:

{
  entry: {
    foo: path.join(__dirname, "src", "js", "foo.js")
  },
  excludeEntriesToHotReload: ["foo"]
  ...
}

Tell me if it does the work.

[vire]

@samuelsimoes I'm working on something similar using this boilerplate as baseline, but excludeEntriesToHotReload does not do anything, I've never found that option...

But if I wan't a contentscript to be excluded I'll do it in webserver.js where you enrich the config.entries as you do in master branch with the excludeEntriesToHotReload

I don't know if excludeEntriesToHotReload is a good option to put in webpack.conf.js (because it implies it's a standard way...

[samuelsimoes]

@vire I got your point, my intention was keep the "util scripts" untouched. The objective is: I need to exclude some entries to the hot reload and I have two ways:

The first is to put to the developer to declare on the webpack config file the webpack hot reloads entries points on each entry point that he wants hot reload, actually it's automatically done here https://github.com/samuelsimoes/chrome-extension-webpack-boilerplate/blob/master/utils/webserver.js#L15-L16.

The second is keep it automatic like it's today and use some sort of key on the webpack config to tells to webserver ignore some entries.

I understand your misgiving about this non-standard key, but I thought that it's the most ergonomic way to do this and it helps the people that want to update the boilerplate since the people don't touch the utils folder.

What do you think?

[vire]

I think it's okay with a comment, in the webpack.conf.js about the property is being used for some purpose.

It's the best to keep things simple and explicit

[myktra]

This approach doesn't seem to update the manifest.json file that gets written to the build folder. Seems like excluding the entry from hot reloading also excludes it from being written to the output manifest.json properly.

Ex: I'm seeing a foo.bundle.js get written, but the manifest continues to refer to foo.js. Manually editing the manifest.json to refer to foo.bundle.js restores the desired behavior.

Also, how would one get a CSS content script deployed correctly? ex:

"content_scripts": [
  {
    "matches": ["http://www.google.com/*"],
    "css": ["foo.css"],
    "js": ["foo.js"]
  }
]

If foo.js imports foo.css this seems to place the CSS in the output via webpack, but build output for a Chrome extension requires it to be a separate file, no?

[samuelsimoes]

@myktra sorry for the late response, I think that I expressed myself badly on my comments above, but you must place in the manifest.json the name of the bundle, not the entry.

If your webpack config is:

  ...
  output: {
    path: path.join(__dirname, "build"),
    filename: "[name].bundle.js"
  },
  ...

your manifest must be

  ...
  "content_scripts": [
    {
      "matches": ["https://www.google.com/*"],
      "js": ["<entry name>.bundle.js"]
    }
  ],
  ...

About the CSS on a separate file, it is a personal choice, I created the boilerplate staying close to the webpack's defaults, where the default is the CSS through javascript. I made a test here and the injected javascript injecting style seems works, but you could extract the CSS in a separate file using this plugin https://github.com/webpack/extract-text-webpack-plugin

[myktra]

Yep, that all makes sense, and just arrived at a similar conclusion yesterday after my own testing and meant to post here...thanks!

[howardya]

@samuelsimoes I was reading through exactly this issue and was very eager to make the hot reloading of contentscript work as most of my work is in the contentscript.

I found out about this https://github.com/xpl/crx-hotreload and it seems to work. I just need to drop that script as my backgroundjs and it indeed is hot reloading the content script. Do you forsee any problem with it?

Hope it is useful for those needing it (like me) !

thanks.

[ARMATAV]

@howardya Can you give a step-by-step breakdown of exactly what you did in order to get the hot reload working with a content script? When I put it in as a "background": { "scripts": ["hot-reload.js"] } it is unable to find hot-reload.js.

This part is sort of unclear for me:

I just need to drop that script as my backgroundjs and it indeed is hot reloading the content script.

[wholegroup]

@ARMATAV

1. save hot-reload.js to js folder

2. import hot-reload script in background.js

import '../img/icon-128.png'
import '../img/icon-34.png'

import './hot-reload'

3. add chromeExtensionBoilerplate section to webpack.config.js

  entry: {
    popup: path.join(__dirname, "src", "js", "popup.js"),
    options: path.join(__dirname, "src", "js", "options.js"),
    background: path.join(__dirname, "src", "js", "background.js")
  },
  chromeExtensionBoilerplate: {
    notHotReload: ["background"]
  },