Build universal para extensão e userscript

[rodorgas]

Motivação

Hoje temos dois repositórios separados para o código da extensão de navegador e do userscript. Isso gera trabalho de desenvolvimento e manutenção dobrado, e é comum adicionar ou atualizar um site em um dos repositórios e esquecer de atualizar o outro. Similarmente, quase todas as contribuições externas são feitas em apenas um dos repositórios.

Esse é um grande problema não apenas de duplicação total do código, mas também de duplicação de projeto, com todas as etapas do desenvolvimento, teste e lançamento.

A solução para esse problema é ter um mecanismo de build que, a partir do mesmo código-fonte, gera o userscript e a extensão usando a WebExtensions API. Futuramente, podemos incluir um mecanismo para gerar também a extensão para o Safari, um filtro para uBlock Origin, entre outros (existem outras ferramentas que podem ser usadas para burlar notícias?).

Para isso, precisamos criar uma espécie de especificação declarativa que nos permita definir as regras de comportamento, e um builder seria responsável por converter essas regras em código compatível com cada uma das plataformas, como mostra o diagrama:

Proposta

Para os arquivos de configuração, proponho usarmos YAML. Uma vantagem em relação ao JSON são as literais multilinha: precisamos incluir trechos de código JS no arquivo de configuração e em JSON tudo teria que ficar na mesma linha. Além disso, YAML suporta comentários, que podem ser úteis.

Uma possível estrutura dos arquivos seria:

|-- src
    |-- rules
        |-- site1.yaml
        |-- site2.yaml

E os arquivos seguiriam uma estrutura mais ou menos assim:

block:
  - type: script
    - match:
      - "*://host/path1"
      - "*://host/path2"

cookieBlocking:
  match: "*://host/*"
  cookies: "*"

contentStart:
  match: "*://host/path*"
  code: |
    multiline
    code
    here

Questões

Existem diversas questões em aberto:

1. Não há paridade completa de funcionalidades entre a WebExtensions API e o userscript. Seria interessante atualizar automaticamente alguma documentação (README ou o site do projeto) com a lista atualizada de quais sites funcionam em qual plataforma. Além disso, às vezes implementamos uma estratégia incompleta no userscript e uma mais completa na extensão. Precisamos de uma forma de selecionar estratégias diferentes .
2. Eu gosto da ideia da configuração inteira de um site ficar reunida num único arquivo. Parece bom para a organização e simplifica o processamento. No entanto, como esse arquivo de configuração pode incluir código JS, perdemos linting e realçador de sintaxe nos editores de texto (mas o lint pode ser resolvido durante a fase de build). Existem estruturas de arquivo alternativas, por exemplo em que cada site é uma pasta com múltiplos arquivos que podemos considerar.
3. Dois sites diferentes podem usar o mesmo código? Por exemplo, alguns sites da Abril tem domínios completamente diferentes mas podem usar o mesmo método de contorno. Alguns sites diferentes usam serviços como o tinypass, talvez possamos ter um arquivo de configuração do tinypass ou da Veja, configurado para ser aplicado em vários sites. Isso violaria um pouco da ideia de ter a configuração inteira de um site reunida num único arquivo, mas permite reaproveitamento de código.
4. O que vamos usar como bundler/builder/transpiler? O Webpack parece um candidato natural e já apareceu em conversas anteriores (Implementar Webpack #315), temos outras opções? Independente da ferramenta vamos ter que escrever o código pra converter o YAML em extensão/userscript, pois até onde vi não existe nada parecido. O Webpack substituiria completamente o Makefile? O Taskfile parece interessante também. Alguns desenvolvedores no Windows já tiveram dificuldades em usar make antes, não sei se isso ainda é um problema com WSL e se alguma decisão aqui poderia beneficiá-los.

cc @CaioWzy

[rodorgas]

Relevante: burlesco/userscript#10

[rodorgas]

Sobre o ponto 2, ao invés de ter uma configuração yaml, poderia ser um JS que exporta um objeto. Dessa forma fica mais fácil ter linting/realçado de sintaxe.