[CLKF-87] Implementa controle de locale no package verify

[bob-clk]

Descrição

package/verify

• Renomeia pacote identity-authenticator para verify
• Renomeia classe para ClicksignVerify
• Adiciona prefixo verify no path do endpoint
• Cria lógica para configurar locale
• Cria testes unitários categorizados:
  • Start
  • Locales
  • Events
  • Unmount
• Substitui Jest por Vitest
• Substitui Yarn por Pnpm

package/widget

• Move package v2 para widget

package/widget/v1

• Renomeia pasta v1 para legacy e move para package/widget

Issue tracker

CLKF-87

Screenshots (para mudanças de UI, se houver)

Links e observações

Checklist para poder mergear

• O código do PR inclui (ou já possui) testes para o código nele
• Os checks de linters estão passando
• Os checks de testes estão passando

[franciscoemanuel-clk]

Poderíamos usar a URL do app-workspaces de production:

Suggested change

	this.endpoint = 'https://app.clicksign.com';
	this.endpoint = 'https://app.clicksign.com/app/verify/';

PS: Ainda vai ser necessário alterar lá no app-workspaces o namespace pra verify

[bob-clk]

O endpoint é configurável a nível do cliente. Não seria mais viável manipular isso diretamente na lógica do path como foi feito?

:link

embedded/packages/verify/src/embedded.js

Lines 63 to 67 in 5c609d7

	get path() {
	if (this.locale) return `/verify/${this.locale}/sessions/${this.key}`;
	return `/verify/sessions/${this.key}`;
	}

Ficando diretamente assim:

 get path() { 
   if (this.locale) return `app/verify/${this.locale}/transactions/${this.key}`; 
  
   return `app/verify/sessions/${this.key}`; 
 } 

1. Seguindo o padrão do widget embedded, o endpoint está apontando direto para o "host" (ambiente) sem path. Quem já utilizar outro embedded pode se guiar pelo padrão de instalação/configuração.
2. Em caso de mudanças de paths é masi fácil disponibilizar uma atualização do script (mantendo ou não um suporte com redirect pro path legado) ou solicitar e aguardar que os clientes atualizem suas configurações?

Eu acredito que é mais prático o controle do nosos lado.

Exemplo (hipotético e exagerado) que o cliente externo precisaria alterar em caso de mudanças internas de roteamento:

this.endpoint = 'https://app.clicksign.com/outro-prefixo/outro-path/subpath/...';

[bob-clk]

Esse arquivo não deveria ser inserido, estamos usando o yarn no projeto (por enquanto).
Ter 2 "package".lock trás uma "crise de identidade" e pode gerar alguns problemas a nível local como incosistencia de versões.

O gerenciamento da pasta node_modules são totalment diferentes entre as ferramentas: yarn (flattening) e pnpm (symlinks). E em caso de alternar entre os dois pode corromper a pasta de instalações, forçando a remoção total da pasta/reinstalação constantemente.
Acredito que não seja nosso caso, mas também pode gerar problemas também em CI: problema com detecção automática do instalador, duplicidade de build (se processar ambos), invalidação de cache desnecessário e etc.

[bob-clk]

Caso queira executar a tarefa de migração, devido a complexidade do projeto e principalmente no uso em CI. Indico fazer em um pull request à parte.