fix: tag default variant

[viniciuslagedo]

Summary

Resolve #1740

Examples

<Tag>Label</Tag> // renders secondary gray label
<Tag variant="primary">Label</Tag> // renders primary gray

[vercel]

Deployment failed with the following error:

You don't have permission to create a Preview Deployment for this project.

View Documentation: https://vercel.com/docs/accounts/team-members-and-roles

[viniciuslagedo]

I believe it will cause a breaking change

[lucasaarcoverde]

I believe it will cause a breaking change

Sim, isso causa uma breaking change no comportamento do código e visual também! Nós entendemos que isso pode ocorrer mais vezes em outros lugares e é um tradeoff de uma breaking change majoritariamente visual vs uma melhoria na DX desse componente.

Nesse caso, conversei com @matheusps pra gente resolver esse problema e conseguir passar esse tipo de mudança. A ideia é tratar como um bug fix e criar alguma tag no JSDoc que indique essa mudança. Alguma anotation como @changed algo assim que simbolize isso na documentação. Ainda estou pensando melhor como fazer isso, você tem alguma sugestão?

Compartilhando aqui só pra dar uma resposta em relação ao PR, uma vez que a gente definir isso podemos fazer o merge e criar uma issue para a atualização dessa anotation na documentação 😄

[lucasaarcoverde]

Outro ponto: a gente até então não tinha utilizado o Breaking Change: no commit pois a lib estava na 0.x e toda mudança era uma possível breaking change. O problema é que essa anotação faz a release automática gerar uma versão major caso não seja tratado corretamente, que é o caso agora. Caso esse PR seja mergeado será lançado a 2.x. Para evitar isso criei esse PR #1872. Falta testar ainda o comportamento, uma vez que estiver testado e mergeado ai esse fica livre

[viniciuslagedo]

Outro ponto: a gente até então não tinha utilizado o Breaking Change: no commit pois a lib estava na 0.x e toda mudança era uma possível breaking change. O problema é que essa anotação faz a release automática gerar uma versão major caso não seja tratado corretamente, que é o caso agora. Caso esse PR seja mergeado será lançado a 2.x. Para evitar isso criei esse PR #1872. Falta testar ainda o comportamento, uma vez que estiver testado e mergeado ai esse fica livre

Faz muito sentido! Boa!

[viniciuslagedo]

Sim, isso causa uma breaking change no comportamento do código e visual também! Nós entendemos que isso pode ocorrer mais vezes em outros lugares e é um tradeoff de uma breaking change majoritariamente visual vs uma melhoria na DX desse componente.

Nesse caso, conversei com @matheusps pra gente resolver esse problema e conseguir passar esse tipo de mudança. A ideia é tratar como um bug fix e criar alguma tag no JSDoc que indique essa mudança. Alguma anotation como @changed algo assim que simbolize isso na documentação. Ainda estou pensando melhor como fazer isso, você tem alguma sugestão?

Compartilhando aqui só pra dar uma resposta em relação ao PR, uma vez que a gente definir isso podemos fazer o merge e criar uma issue para a atualização dessa anotation na documentação 😄

Saquei, me parece ser um bom caminho de fato, estamos com uma mudança pequena mas ainda assim uma breaking change. Eu vi que tem aquelas annotations @since e @deprecated talvez seja um caminho.