Biblioteca baseada no Vuetify, como nós usamos e dicas para evitar problemas de performance

Version in English

Introdução

Como construir um Design System dentro de uma startup?
Sou Rafael Bastiansch, Tech Lead de Frontend responsável por esta arquitetura e vou mostrar como construímos um design system na Logcomex e ajudá-lo a construir uma ferramenta semelhante para seus projetos pessoais ou no trabalho, vou mostrar nossa stack hoje e porque nossa biblioteca foi construída desta forma.

Para que você se sinta confortável com nosso negócio, vou explicar nossos projetos na Logcomex:

• o maior é um monolítico, que compartilha finalidades diferentes.
• novos projetos são criados com Nuxt.

Queríamos criar nossos novos projetos com o mesmo design, mas em repositórios separados, então tivemos que reutilizar nossos componentes básicos. A ideia foi criar uma biblioteca que compartilhasse nossos códigos.

Nossa primeira versão com rollup

A primeira versão foi construída com rollup, mas tive alguns problemas logo no inicio. Usando componentes complexos de vuetify e scss separados, começou a gerar alguns erros para compilar a biblioteca. Então tive que descobrir o que estava acontecendo e, depois de algumas POCs, experimentei o Vue-CLI e funcionou perfeitamente. Por falta de tempo decidimos continuar a usá-lo.

Versão com Vue-CLI

Vue-CLI tem alguns bons recursos embutidos para usar, gerar componentes Vue para biblioteca é um deles, naquela época como desenvolvimento inicial e necessário construir algo rápido foi uma boa escolha.

Para criar uma biblioteca com Vue-CLI, iniciamos um projeto seguindo as instruções e adicionamos algumas configurações ao vue.config.js

const path = require('path');

module.exports = {
  configureWebpack: {
    resolve: {
      alias: {
        "~": path.resolve(__dirname)
      }
    },
  },
  css: {
    loaderOptions: {
      sass: {
        additionalData: `
          @import "@/assets/scss/_main.scss";
        `
      }
    }
  }
}

e adicionar o script para o package.json para buildar nossa lib

...
"scripts": {
    "build": "vue-cli-service build --target lib src/index.js",
},
...

A estrutura de nossa lib possui o arquivo src/index.js, é onde importamos todos os meus componentes e os preparamos para serem importados quando outro projeto estiver usando este pacote. Você pode verificar mais sobre isso aqui: Vue cookbook

export * from './components/inputs'
import * as inputs from './components/inputs'


const components = {
    ...inputs,
}

export function install (Vue) {
    for (const [name, component] of Object.entries(components)) {
        Vue.component(name, component)
    }
}

const plugin = {
  install
}

let GlobalVue = null;
if (typeof window !== "undefined") {
  GlobalVue = window.Vue;
} else if (typeof global !== "undefined") {
  // eslint-disable-next-line no-undef
  GlobalVue = global.Vue
}
if (GlobalVue) {
  GlobalVue.use(plugin);
}

export default plugin;

Basicamente, esses são todos os arquivos que você precisará para criar/modificar sua própria biblioteca com Vue-CLI.

Versão atual e problemas

Estamos rodando nossa versão atual de build usando o Vue-CLI por quase um ano, continua da mesma forma que foi feita e até hoje é bom para nós... mas temos algumas melhorias a fazer. Fizemos isso pensando em nossos projetos atuais, então temos que mantê-los compatíveis.

Como encontramos alguns erros ao consumir, mantemos as bibliotecas externas construídas em nosso pacote e isso é um problema, o tamanho do pacote aumenta à medida que adicionamos novos recursos que requerem instalações externas. Atualmente, o tamanho é 219KB compactado.

Nova versão com algumas correções

Agora estou trabalhando para melhorar isso, primeiro de tudo eu defini todos os pacotes de terceiros como externos, isso reduziu o tamanho do nosso arquivo antigo para 58KB compactado, quase 4 vezes menor do que antes. Para conseguir isso, você deve definir as bibliotecas como externals no vue.config.js dentro da chave configureWebpack e ele não irá mais compilar junto.

...
externals: [
  'dayjs',
  'moment',
  'ramda',
  'sortablejs'
],
...

e migrar algumas dependências para devDependencies(desculpe, erro meu). Essas são as alterações que estou fazendo, depois de usarmos esse novo build para produção, veremos se será suficiente ou se iremos procurar mais melhorias em nossa biblioteca.

Se você quiser dar uma olhada e usar ou contribuir, será mais do que bem-vindo.
Projeto no github
Nova branch com as melhorias

Comments

[Gustavo Ramos]

Muito bom Rafael, parabéns pelo empenho em entregar o nível de qualidade que temos hoje no Design System!
Pelo o que já pude utilizar realmente é um projeto excelente e que está em constante evolução.

[Rafael Bastiansch]

Muito obrigado Gustavo, só conseguiria fazer isso com um time foda que temos!
Espero que a evolução continue sempre.

[Calebe Aires]

Hey amigo. Bom artigo.

Uma pergunta: ao migrar algumas bibliotecas como externals (dayjs, ramda...), elas deixam de ser copilidas no build certo? Mas como você as utiliza na aplicação principal fica a dúvida, elas serão, mesmo assim, levadas para o build?

[Rafael Bastiansch]

Opa, obrigado.

Eu coloco elas como devDependencies, ai no import do meu dist vai continuar import dayjs from 'dayjs', mas vai pegar do node_modules do projeto que instalou a minha lib.