Olá pessoal, somos da www.strongway.com.br , e queremos, primeiramente, agradecer por ter tornado este projeto open source.
No intuito de tentar ajudar nas melhorias do projeto, verifiquei o roadmap de vocês. Um dos itens citados é: "Melhorar estrutura do projeto".

Vocês têm alguma ideia dos problemas de estrutura a resolver, ou alguma ideia de que linha querem seguir nesse sentido?

Vou marcar o @JuniorPaula para acompanhar.

Descrição

Ao rodar o comando tray new incluindo o parâmetro theme_base não surtiu o efeito esperado. O novo tema, em vez de ser baseado no tema base, foi gerado a partir do tema padrão da Tray.

Descrição

Como usuário do CLI gostaria que a ferramenta verificasse o tipo do arquivo a ser enviado e comunique caso ele não seja compatível.

Motivo

Ao desenvolvermos um tema estamos constantemente trabalhando com vários tipos de arquivos e podemos não nos atentar ao tipo do arquivo no momento em que criamos. Sem uma validação disso podemos desprender tempo averiguando algo que não é um bug ou problema, e sim uma limitação.

E ai galera, beleza?

Estou tentando alterar um tema aqui e ao tentar rodar o comando tray configure [key] [pass] [theme_id] estou recebendo a mensagem de que alguma dessas informações estão erradas.

Não estou certo sobre o THEME_ID, é o numero que está na URL ao editar um tema na plataforma da tray (https://opencode.tray.com.br/v2/themes/THEME_ID/customizations)?

Fico no aguardo.

Obrigado!

Descrição

Eu, como desenvolvedor, gostaria de ver as mudanças de script refletidas em tempo real, ao salvar os documentos originais em .ts, durante o desenvolvimento de mudanças no projeto.

Motivo

Rodar o comando npm run build toda vez que um arquivo .ts é editado torna o trabalho muito tedioso e lento. Para grandes alterações, até que não seria o problema, mas se cada pequena mudança a ser testada requerer a ativação desse comando, o trabalho pode demorar demais e ser muito frustrante. Isso é algo especialmente comum quando estamos iniciando e fazendo os primeiros experimentos.

Descrição

Eu como usuário da ferramenta gostaria de ter uma comunicação visual mais simplificado do que está acontecendo e dos status do processamento. Como desenvolvedor da ferramenta gostaria de simplificar e melhor o usa das chamadas de comunicação com o usuário.

Motivo

Uma boa comunicação com o usuário que está usando a ferramenta proporciona mais clareza na resolução de problemas e na descrição da situação atual do ocorrido, incorrendo em menos tempo para que uma ação efetiva seja tomada.

Detalhes

Podemos usar o pacote Ora que permite dar uma feedback simples, rápido e eficiente sobre a situação atual do programa.

Descrição

Como usuário do CLI gostaria de poder usá-lo em diferentes versões do Node.js, garantindo maior compatibilidade com as outras ferramentas que já utilizo no dia a dia.

Motivo

Hoje o CLI garante o funcionamento somente com a versão mais recente do Node.js (release current), o que pode quebrar a compatibilidade com outras ferramentas usadas em produção. Acredito que o ideal seria suportar as versões LTS disponíveis pelo Node.js e estar alinhado com o roadmap deles, abrangendo assim os melhores cenários.

Descrição

Como desenvolvedor de temas, gostaria que o comando tray themes retornasse apenas os temas ainda disponíveis no painel.

Motivo

Atualmente o comando mostra todos os temas que já existiram em uma determinada loja, pois, como é descrito na documentação, os temas excluídos permanecem na plataforma. Como desenvolvedores, geramos muitas cópias de temas, e esse relatório fica poluído se mostrar temas antigos excluídos.

Detalhes

Acredito que esse comando deva ser alterado para mostrar apenas os temas não excluídos. Para mostrar os excluídos, aí podemos utilizar uma flag específica. Exemplo: tray themes --include-deleted. Pode ter um alias também, como --d

Descrição

Eu como usuário do CLI gostaria que a ferramenta permitisse a criação de um log de todos os eventos realizados e registrasse tudo o que ocorresse, desde alertas até erros falso positivos/negativos.

Motivo

No decorrer dos meses a Tray pode implantar novas funcionalidades ou realizar alterações nos endpoints da API que podem gerar falsos positivos / negativos ou mensagens de erros e não teríamos como analisar se é um erro do CLI ou da API. Ao permitir que um log fosse habilitado pelos desenvolvedores, haveria um registros das atividades e possíveis problemas, facilitando a identificação.

Dependência

Esse funcionalidade depende da implementação de:

• #10
• #12

Descrição

Eu como desenvolvedor gostaria que existisse um padrão de abertura de Issues no projeto, de acordo com o tipo de Issue a ser aberta.

Motivo

Criar um padrão para abertura das Issues permitirá identificar rapidamente sobre o que ela se refere, e se for para comunicar um problema, ela pode montar um formato que provê mais detalhes que facilita verificar o problema e, se for o caso, aplicar uma correção adequada.

Olá pessoal, primeiramente, parabéns pelo projeto. Certamente vai ajudar muitas pessoas mesmo. Eu não tenho tanto conhecimento pra contribuir mais, mas pretendo ajudar no pouco que puder. Estava fazendo alguns teste, e sempre que altero algum arquivo scss, o watch retorna erro 500 - internal error.

Não sei se aqui é o lugar certo de perguntar isso, me desculpe se fiz errado, mas gostaria de relatar isso. O restante está funcionando tudo ok.

Descrição

Eu como usuário do CLI gostaria de poder enviar somente as pastas principais 'core' do tema. As demais pastas específicas, como imagens, seriam feitas por um comando a parte.

Sugestão indicada pelo @thiagofloriano

Motivo

Muitas vezes queremos enviar somente uma base do tema para não poluir o tema com coisas que não farão sentido, como imagens ou scripts adicionais. Para isso um comando de upload core seria interessante. Como sugerido pelo @thiagofloriano seria enviado apenas a base essencial da Tray settings / css / js / pages / layout. Imagens e outras particularidades seriam enviadas a parte.

Dependência

Esse funcionalidade depende da implementação de:

• #17

Ao baixar um arquivo pode ocorrer um erro na requisição com status diferente de 2xx. Com isso cai no bloco catch. Porém esse bloco tenta pegar os dados sem verificar se existir algum retorno, ocorrendo erro undefined.

Passos para verificar

• Tentar fazer o download de um arquivo de modo que ele de erro, diferente de status 200.
• Verificar que ocorre o problema ao tentar recuperar a mensagem ao pegar os dados (linha 256 arquivo TrayApi.js)

Delete-theme not working.
Response from Api is: Error from api: Layout inválido

Descrição

Eu como usuário do CLI gostaria de poder usar a ferramenta no meu sistema operacional preferido, estou acostumado, ou ao qual serve para meu workflow.

Motivo

Existes vários sistemas operacionais, cada qual voltado a um mercado ou finalidade específica. Ao fazer a ferramenta ser compatível com vários sistemas operacionais permite que mais pessoas possam usufruir dos benefícios que ela traz, além de não forçar uma mudança no ambiente que funciona para determinado indivíduo ou trabalho.

Detalhes

Acredito que os principais sistemas que deveriam ser suportados são:

• Windows 10
• macOS 11
• macOS 10.15
• Ubuntu 20.04
• Ubuntu 18.04

Descrição

Eu como desenvolvedor gostaria que na documentação do projeto constassem as opções de cada comando e os novos comandos disponíveis.

Motivo

Atualizar a documentação com as novas opções e comandos disponibilizados pelas novas versões tornará mais fácil o uso e, possivelmente, a adesão de novos usuários ao projeto.

Descrição

Eu como desenvolvedor do CLI gostaria de separar o desenvolvimento do CLI do SDK para integração com a API do Opencode da Tray.

Motivo

Ao desenvolvedor uma ferramenta ou biblioteca, englobar tudo em um único projeto pode tornar o desenvolvimento confuso e conturbado. Separar o desenvolvimento do CLI do SDK irá permitir focar em melhorar cada parte separadamente, e permitir que elas ainda funcionem um conjunto, mesmo que a partir de uma versão, uma se torne incompatível com a outra.

Descrição

Eu como usuário da ferramenta gostaria de uma comunicação clara quando erros ocorrem, no meu idioma principal. Como desenvolvedor gostaria padronizar os erros gerados e simplificar a captura deles.

Motivo

Uma comunicação clara do problema facilita a tomada de decisões e permite continuar o desenvolvimento mais rápido. Além disso gera um código mais fácil de ler, escrever e manter.

Detalhes

Acredito que podemos focar nos seguintes pontos:

• Criar um padrão de erros, utilizando a classe Error para obter tudo o que ela já traz.
• Fazer uma captura geral, de modo a simplificar a manutenção
• Validar possíveis falsos positivos / falsos negativos retornados pela API

Descrição

Eu, como desenvolvedor, gostaria de poder subir conjuntos específicos de arquivos, em vez de todos (ou apenas arquivos muito selecionados).

Motivo

Hoje o comando upload só nos dá duas opções: subir todos os arquivos do tema, ou escolher exatamente quais arquivos subir. Em algumas ocasiões, é interessante subir todos os arquivos de uma pasta.

Ex: /js/min/* - é um caso interessante, pois às vezes não sabemos se um problema depende de vários arquivos ou um só, e subir todos os arquivos de uma pasta "suspeita" permitiria verificar rapidamente.