[ext] Allow the extension to connect to dev-env

[sigmike]

related issues #1850

---

Description

These changes add a new script prepareExtension.js that generates the manifest.json and a new config.js. This allows us to generate an extension that connects to the dev-env (and other environments can be added).

I ended up making a script instead of using a vite plugin because the plugins actually implied some unnecessary changes to the extension code, we don't need all the features the plugin provides, and I didn't feel comfortable adding so many new dependencies. The only dependency added here is node. But if we ever want to use TypeScript or React in the extension I think the best solution is to use the rollup version of this plugin: it's quite minimal and is very similar to what I did in the script.

To get all the content scripts to connect to the right servers, we need to import the config. Since content scripts can't use static imports, this would require wrapping all of them inside an anonymous async function to use the dynamic import. To avoid this, and to make development easier by enabling static imports in content scripts I copied the above plugin's method of replacing the content scripts in the manifest with small import wrappers that only import the actual content script.

The only references to the Tournesol production servers that I didn't change are inside HTML files:

• the Tournesol logo
• the link to Tournesol in the options
• the iframe in the options

These references are not very important to change when we are working on the extension, but it may be confusing to have links to the production servers when we are setting up the environment to not use production. I'm not sure what the best way is to change them. The easiest and safest way is probably to write these references in javascript at runtime.

Checklist

• I added the related issue(s) id in the related issues section (if any)
• I described my changes and my decisions in the PR description
• I read the development guidelines of the [CONTRIBUTING.md][development-guidelines]
• The tests pass and have been updated if relevant
• The code quality check pass

[GresilleSiffle]

It looks very good to me 👌 it was very easy to use my local environment.

Regarding the remaining hardcoded links in the options, as you suggested we can dynamically write them with JavaScript. There is already a script options.js responsible of configuring the behaviour of the page options.html.

[sigmike]

Regarding the remaining hardcoded links in the options, as you suggested we can dynamically write them with JavaScript. There is already a script options.js responsible of configuring the behaviour of the page options.html.

I did that in 21414ca.

As discussed elsewhere I also:

• moved the version into package.json: 0c5910e
• added a yarn prepare to prepare the script (and also added a yarn prepare:dev): 55eda53

[GresilleSiffle]

Thank you.

@amatissart do you also want to have a look before merging?

I read the documentation about .eslintrc file cascading, and if I understood correctly it could be a good idea to define the key root: true in the root .eslintrc file. This will prevent unexpected configuration merging if ESLint checks all parent folders until the root directory.

By default, ESLint looks for configuration files in all parent folders up to the root directory. This can be useful if you want all of your projects to follow a certain convention, but can sometimes lead to unexpected results. To limit ESLint to a specific project, place "root": true inside the .eslintrc.* file or eslintConfig field of the package.json file or in the .eslintrc.* file at your project’s root level. ESLint stops looking in parent folders once it finds a configuration with "root": true.

https://eslint.org/docs/latest/use/configure/configuration-files#cascading-and-hierarchy

[sigmike]

it could be a good idea to define the key root: true in the root .eslintrc file.

It's indeed good to not merge the files, but as I understand it, to do that the root: true should be in the src's eslintrc, not the root one. It means eslint will not merge it with the root eslintrc when parsing src files. I did that in aa2ca2a.

[sigmike]

I discovered that the prepare script is automatically started when you run yarn install. I think it doesn't matter too much here, but it may still be quite surprising to have the extension switched back to production environment because you added a package or something.