{"id":1851,"date":"2017-06-21T15:11:52","date_gmt":"2017-06-21T18:11:52","guid":{"rendered":"http:\/\/www.milfont.org\/tech\/2017\/06\/21\/transformando-seu-codigo-de-negocio-em-biblioteca-versionada\/"},"modified":"2017-06-21T15:11:52","modified_gmt":"2017-06-21T18:11:52","slug":"transformando-seu-codigo-de-negocio-em-biblioteca-versionada","status":"publish","type":"post","link":"https:\/\/www.milfont.org\/tech\/2017\/06\/21\/transformando-seu-codigo-de-negocio-em-biblioteca-versionada\/","title":{"rendered":"Transformando seu c\u00f3digo de neg\u00f3cio em biblioteca versionada"},"content":{"rendered":"

Um problema comum no Frontend \u00e9 o gerenciamento e organiza\u00e7\u00e3o do c\u00f3digo e as \u00faltimas tecnologias nos \u00faltimos anos<\/a> nos ajudam a resolver.<\/p>\n

Caso<\/h3>\n

Tenho um c\u00f3digo que depende de mapas<\/a> em v\u00e1rias telas do sistema e organizei um componente que pode ser importado em v\u00e1rios arquivos.<\/p>\n

Como esse componente tem um ciclo de desenvolvimento diferente, organizei como subm\u00f3dulo no git.<\/p>\n

\n


\n<\/figure>\n

Para facilitar, os devs importam o projeto principal com par\u00e2metro pra j\u00e1 carregar os subm\u00f3dulos, mas no final de contas fica tudo num mesmo lugar.<\/p>\n

git clone --recursive -j8 git@github.com:cmilfont\/beerswarm.git<\/code><\/pre>\n
Problema<\/h3>\n
O c\u00f3digo est\u00e1 blindado para importar as depend\u00eancias sem se preocupar com estrutura e organiza\u00e7\u00e3o, j\u00e1 que nos foi dada com a nova abstra\u00e7\u00e3o na linguagem\u200a\u2014\u200atranspilada<\/strong> pelo Babeljs<\/a>\u200a\u2014\u200apara funcionar em todos os navegadores, algo como:<\/p>\n
import { BMap, Toolbar, GoogleMutant, GoogleApiLoader } from '\/components\/maps';<\/pre>\n
O problema mesmo \u00e9 no ciclo de vers\u00e3o desses componentes. Se um desenvolvedor move um m\u00e9todo de lugar e o projeto n\u00e3o tem 100% de cobertura em testes (se tratando de legado \u00e9 o normal e esperado) corre o risco prov\u00e1vel de detectar apenas em produ\u00e7\u00e3o.<\/p>\n
Problema dobrado, uso o Leaflet<\/a> como gerenciador de mapas, cada fornecedor representa uma camada (layer) a ser exibido, o default \u00e9 o Open Street Maps<\/a>.<\/p>\n
Para usar o mapa do Google teria que implementar uma layer e carregar a API, causou o problema com outra tela que precisava al\u00e9m do Mapa tamb\u00e9m carregar a biblioteca de places<\/strong> que faz parte dos opcionais. Da\u00ed nasce o subm\u00f3dulo do subm\u00f3dulo pra gerenciar.<\/p>\n
Problemas secund\u00e1rios que tamb\u00e9m tomam tempo da equipe: merges desmotivantes.<\/p>\n
Solu\u00e7\u00e3o<\/h3>\n
Transformar esses c\u00f3digos gen\u00e9ricos em bibliotecas<\/a> com seu pr\u00f3prio ciclo de versionamento usando o pr\u00f3prio gerenciador de pacotes do Nodejs, o npm<\/a>, como fazem as bibliotecas OpenSource da linguagem.<\/p>\n
Hospedando o projeto da\u00a0lib<\/h4>\n
Come\u00e7amos por isolar a Layer do Google a ser usada no Leaflet como uma lib.<\/p>\n
Usando o create-react-app<\/strong> (troque pelo seu boilerplate preferido) eu criei um projeto novo https:\/\/github.com\/produtoreativo\/react-leaflet-googlemutant<\/a>, adicionei repositorio no github.<\/p>\n
Formato 1: Open Source<\/strong><\/p>\n
Se n\u00e3o tem diferencial pro meu neg\u00f3cio (como uma Layer para o mapa do Google) o melhor \u00e9 deixar o mundo ajudar a manter, reservando um reposit\u00f3rio no npmjs.com<\/a>.<\/p>\n
Formato 2: Privado no npmjs.com<\/strong><\/p>\n
O registro global de libs no nodejs tem planos pagos para libs privadas<\/a>, tem tamb\u00e9m que colocar private: true<\/strong> no package.json<\/strong> do projeto. Conveniente por ser a mesma coisa do OpenSource, mas talvez um pre\u00e7o salgado dependendo do tamanho da sua companhia.<\/p>\n
Formato 3: Privado e hospedado in-house.<\/strong><\/p>\n
Caso queira hospedar seu pr\u00f3prio reposit\u00f3rio de bibliotecas, pode usar uma op\u00e7\u00e3o como o Nexus<\/a> e apontar no package.json o caminho como a pr\u00f3pria documenta\u00e7\u00e3o da ferramenta ensina<\/a>.<\/p>\n
Formato 4: Privado sem gerenciador de reposit\u00f3rios de libs<\/strong><\/p>\n
Caso ainda n\u00e3o queira configurar um servidor privado ou pagar o registro p\u00fablico global, pode tamb\u00e9m indicar no package.json o caminho ao github diretamente, algo como:<\/p>\n
{
  \"name\": \"beerswarm\",
  \"version\": \"0.1.0\",
\"private\": true,<\/strong>
  \"dependencies\": {
    \/* libs ... *\/
    \"react-leaflet-googlemutant\": \"github:produtoreativo\/react-leaflet-googlemutant<\/strong>\",
  },
  \"devDependencies\": {
    \"react-scripts\": \"0.9.5\",
  },
  \"scripts\": {
    \"start\": \"NODE_PATH=src react-scripts start\",
    \"build\": \"NODE_PATH=src react-scripts build && sw-precache --config=sw-precache-config.js\",
    \"test\": \"NODE_PATH=src react-scripts test --env=jsdom --coverage\",
    \"eject\": \"react-scripts eject\"
  }
}<\/pre>\n
Os devs que tiveram em uma m\u00e1quina com permiss\u00e3o para puxar desse reposit\u00f3rio no seu fornecedor git bastar\u00e3o executar o npm install (<\/strong>ou yarn install)<\/strong> para ter as libs no projeto principal como depend\u00eancia.<\/p>\n
Lembrando que esse \u00faltimo caso de apontar diretamente para o github (ou gitlab) s\u00f3 funciona\u200a\u2014\u200acomo demonstra a pr\u00f3pria documenta\u00e7\u00e3o<\/a>\u200a\u2014\u200ainformando qual commit ou branch no final da url com o pattern #commit-ish.<\/strong><\/p>\n
A vers\u00e3o informada no package.json fica s\u00f3 simb\u00f3lica nesse caso e n\u00e3o define que vers\u00e3o real foi puxada.<\/p>\n
Estrutura da\u00a0Lib<\/h4>\n
\n

\n<\/figure>\n
Com o seu boilerplate preferido\u200a\u2014\u200ano meu caso o create-react-app\u200a\u2014\u200acrie a estrutura do seu projeto e reserve uma pasta (sugest\u00e3o, chamei de lib) para o resultado final que ser\u00e1 empacotado.<\/p>\n
Basicamente precisamos configurar adequadamente o package.json e usar um Module Bundler (construtor que vai transformar seu c\u00f3digo em um projeto execut\u00e1vel no navegador) como Webpack<\/strong><\/a>.<\/p>\n
Quero transformar o import em algo como:<\/p>\n
import { GoogleMutant, GoogleApiLoader } from 'react-leaflet-googlemutant';<\/pre>\n
Configurando o package.json<\/h4>\n
Duas coisas importantes a configurar logo de in\u00edcio, o n\u00famero de vers\u00e3o da lib e de forma recomend\u00e1vel o script que vai ser carregado quando essa lib for importada.<\/p>\n
{
  \"name\": \"react-leaflet-googlemutant\",
  \"description\": \"React leaflet wrapper to GoogleMutant plugin\",
  \"version\": \"0.1.6\",
  \"main\": \".\/lib\/react-leaflet-googlemutant.js\",
  \"private\": false
}<\/pre>\n
Ou seja, quando o usu\u00e1rio faz um import from ‘lib’. <\/strong>Essa Lib vai ser carregada no que voc\u00ea informar em main.<\/p>\n
Utilizei a lib standard-version<\/a> para g<\/a>erenciar as mudan\u00e7as do n\u00famero de vers\u00e3o de forma autom\u00e1tica.<\/p>\n
Outro fator importante de configura\u00e7\u00e3o \u00e9 definir o que vai ficar em dependencies, devDependencies ou peerDependencies<\/a>. Lembrando que para o arquivo final que ser\u00e1 importando num projeto Frontend voc\u00ea pode fazer o ajuste tranquilamente no Webpack.<\/p>\n
Configurando o Webpack<\/strong><\/p>\n
Al\u00e9m de instalar com yarn add -D webpack<\/strong>, criei um arquivo webpack.conf.js<\/strong> na raiz da pasta para iniciar a configura\u00e7\u00e3o.<\/p>\n
Para importar as classes que est\u00e3o no caminho src\/components\/<\/strong> eu criei um index.js que exporta todas as interfaces p\u00fablicas dessa lib.<\/p>\n
export { default as GoogleApiLoader} from 'components\/googleapiloader.js';
export { default as GoogleMutant } from 'components\/googlemutant.js';<\/pre>\n
Ou seja, voc\u00ea pode importar a Lib inteira como<\/p>\n
import ReactLeafletGoogleMutant from 'react-leaflet-googlemutant';<\/pre>\n
ou as duas classes exportadas como no c\u00f3digo mostrado anteriormente:<\/p>\n
import { GoogleMutant, GoogleApiLoader } from 'react-leaflet-googlemutant';<\/pre>\n
Esse arquivo de export vai ser nosso Entry Point. A ponte de entrada para todos os componentes da lib.<\/p>\n
var path = require('path');
var webpack = require('webpack');

module.exports = {
entry: \".\/src\/react-leaflet-googlemutant\/index.js\"<\/strong>
};<\/pre>\n
Definimos as refer\u00eancias din\u00e2micas para os locais que o c\u00f3digo deve encontrar as fontes j\u00e1 que estamos usando caminhos absolutos a partir de um source (src).<\/p>\n
var path = require('path');
var webpack = require('webpack');

module.exports = {
  entry: \".\/src\/react-leaflet-googlemutant\/index.js\",
  resolve: {
    modules: [path.resolve(__dirname, \"src\"), \"node_modules\"]
  }<\/strong>
};<\/pre>\n
Em seguida definimos qual vai ser aquela sa\u00edda que os projetos importar\u00e3o:<\/p>\n
var path = require('path');
var webpack = require('webpack');

module.exports = {
  entry: \".\/src\/react-leaflet-googlemutant\/index.js\",
  resolve: {
    modules: [path.resolve(__dirname, \"src\"), \"node_modules\"]
  },
  output: {
    path: path.join(__dirname, 'lib'),
    filename: \"react-leaflet-googlemutant.js\",
    library: \"ReactLeafletGoogleMutant\",
    libraryTarget: \"amd\"
  }<\/strong>
};<\/pre>\n
Escolhi o formato amd<\/strong> como padr\u00e3o da biblioteca gerada<\/a> por ser um dos mais comuns que funciona para todos os ambientes, seja web ou node, o que facilita testes e integra\u00e7\u00f5es.<\/p>\n
Um fator importante \u00e9 definir as depend\u00eancias e n\u00e3o levar junto no build gerado, exemplo, esse projeto de lib assume que o React e o Leaflet vai existir para ele funcionar, n\u00e3o faz sentido empacotar j\u00e1 que os projetos j\u00e1 o far\u00e3o, voc\u00ea pode definir o que \u00e9 externo:<\/p>\n
var path = require('path');
var webpack = require('webpack');

module.exports = {
  entry: \".\/src\/react-leaflet-googlemutant\/index.js\",
  resolve: {
    modules: [path.resolve(__dirname, \"src\"), \"node_modules\"]
  },
  output: {
    path: path.join(__dirname, 'lib'),
    filename: \"react-leaflet-googlemutant.js\",
    library: \"ReactLeafletGoogleMutant\",
    libraryTarget: \"amd\"
  },
  externals: {
    react: {
        root: 'React',
        amd: 'react'
    },
    'react-dom': {
        root: 'ReactDOM',
        amd: 'react-dom'
    },
    'prop-types': {
      root: 'PropTypes',
      amd: 'prop-types'
    },
    'react-leaflet': {
      amd: 'react-leaflet'
    },
    'leaflet': {
      amd: 'leaflet'
    }
  }<\/strong>
};<\/pre>\n
Existem v\u00e1rias prefer\u00eancias sobre qual formato de source map<\/strong><\/a> (aqui definido pela propriedade devtool<\/strong>), adotei qualquer uma porque essa lib \u00e9 intermedi\u00e1ria e n\u00e3o componente final a ser aplicado em projeto:<\/p>\n
var path = require('path');
var webpack = require('webpack');

module.exports = {
  entry: \".\/src\/react-leaflet-googlemutant\/index.js\",
  resolve: {
    modules: [path.resolve(__dirname, \"src\"), \"node_modules\"]
  },
  output: {
    path: path.join(__dirname, 'lib'),
    filename: \"react-leaflet-googlemutant.js\",
    library: \"ReactLeafletGoogleMutant\",
    libraryTarget: \"amd\"
  },
  externals: {
    react: {
        root: 'React',
        amd: 'react'
    },
    'react-dom': {
        root: 'ReactDOM',
        amd: 'react-dom'
    },
    'prop-types': {
      root: 'PropTypes',
      amd: 'prop-types'
    },
    'react-leaflet': {
      amd: 'react-leaflet'
    },
    'leaflet': {
      amd: 'leaflet'
    }
  },
devtool: 'sourcemap'<\/strong>
};<\/pre>\n
Por fim configurei um plugin para aplicar vari\u00e1veis de ambiente (vou colocar o Version Number da lib dentro do c\u00f3digo) e o babel configurado para stage 2 e praticamente traduzindo apenas ES7, j\u00e1 que espero n\u00e3o usar diretamente no navegador e sim j\u00e1 inclu\u00eddo na tradu\u00e7\u00e3o de outra lib\/projeto. Ler mais sobre configura\u00e7\u00e3o do Babel<\/strong> nesse artigo<\/a>.<\/p>\n
var path = require('path');
var webpack = require('webpack');

module.exports = {
  entry: \".\/src\/react-leaflet-googlemutant\/index.js\",
  resolve: {
    modules: [path.resolve(__dirname, \"src\"), \"node_modules\"]
  },
  output: {
    path: path.join(__dirname, 'lib'),
    filename: \"react-leaflet-googlemutant.js\",
    library: \"ReactLeafletGoogleMutant\",
    libraryTarget: \"amd\"
  },
  externals: {
    react: {
        root: 'React',
        amd: 'react'
    },
    'react-dom': {
        root: 'ReactDOM',
        amd: 'react-dom'
    },
    'prop-types': {
      root: 'PropTypes',
      amd: 'prop-types'
    },
    'react-leaflet': {
      amd: 'react-leaflet'
    },
    'leaflet': {
      amd: 'leaflet'
    }
  },
  devtool: 'sourcemap',
  plugins: [
    new webpack.EnvironmentPlugin(['__VERSION__'])
  ],
  module: {
    rules: [
      {
        test: \/.js$\/,
        exclude: \/(node_modules|bower_components)\/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: [\"react\", \"stage-2\"],
            plugins: [
              ['transform-runtime', {
                \"helpers\": false,
                \"polyfill\": false,
                \"regenerator\": false,
                \"moduleName\": \"babel-runtime\"
              }]
            ]
          }
        }
      }
    ]
  }<\/strong>
};<\/pre>\n
Criei uma task script no package.json chamada transpile com o comando webpack e o resultado final fica extremamente enxuto (j\u00e1 que n\u00e3o transpila classes e outras features do es6 tamb\u00e9m).<\/p>\n
\n

\n<\/figure>\n
Criei um bash script pra rodar todas as tasks necess\u00e1rias pra gerar uma vers\u00e3o, chamado publish.sh<\/strong><\/a><\/p>\n
#!\/bin\/sh -x

yarn release #incrementa a vers\u00e3o, consultar a lib standard-version
VERSION=`node -e \"console.log(require('.\/package.json').version);\"`
NODE_ENV=production __VERSION__=$VERSION yarn transpile
git commit -a -m $VERSION
git push --follow-tags origin master
npm publish<\/pre>\n
Debugger e atualiza\u00e7\u00f5es<\/h3>\n
Uma realidade \u00e9 que precisamos muitas vezes debugar o c\u00f3digo dessa sublib enquanto detectamos alguma evid\u00eancia de problema (atire o primeiro unit test<\/strong> que nunca fez isso), al\u00e9m de atualizar a vers\u00e3o conforme novas necessidades no projeto principal.<\/p>\n
Estamos trabalhando no BeerSwarm 1.0 que precisar\u00e1 da vers\u00e3o v0.1.9 do react-leaflet-googlemutant<\/a> que ainda se encontra na v0.1.8.<\/p>\n
Para tornar isso poss\u00edvel o npm<\/strong> fornece um mecanismo simples para linkar um package local e fazer refer\u00eancia direta.<\/p>\n
Na raiz do projeto, execute o comando npm link.<\/em><\/strong><\/p>\n
[cmilfont@MacBook-Pro-de-Christiano:\/Users\/cmilfont\/projetos\/react-leaflet-googlemutant:master:a635622:]
$ npm link<\/strong>
\/Users\/cmilfont\/.nvm\/versions\/node\/v8.0.0\/lib\/node_modules\/react-leaflet-googlemutant -> \/Users\/cmilfont\/projetos\/react-leaflet-googlemutant<\/strong><\/pre>\n
Agora no projeto da lib voc\u00ea vai executar a task transpile<\/strong> com o par\u00e2metro -w (de watch) pra ficar observando todas as altera\u00e7\u00f5es:<\/p>\n
\n

\n<\/figure>\n
Toda altera\u00e7\u00e3o no source muda automaticamente no Webpack que produz aquela sa\u00edda que planejamos.<\/p>\n
No projeto que importa essa lib rode o mesmo comando, mas indicando qual lib foi linkada npm link react-leaflet-googlemutant<\/em><\/strong>.<\/p>\n
E rode o seu toolset de desenvolvimento hot-loader, no meu caso o yarn start para o create-react-app, todas as modifica\u00e7\u00f5es na lib original causar\u00e3o um “touch” no projeto que linkou causando a imediata recompila\u00e7\u00e3o.<\/p>\n
Ao final de desenvolvimento execute o script bash de gera\u00e7\u00e3o da nova vers\u00e3o, coloque o n\u00famero correto no package.json que vai receber (um yarn upgrade nome-da-lib<\/strong> resolve) e evite quebrar o c\u00f3digo de outros projetos que continuar\u00e3o com a vers\u00e3o anterior.<\/p>\n
Espero que esse pequeno tutorial tenha sido \u00fatil como foi pra mim, quaisquer d\u00favidas comenta ou manda issues no github\u00a0\"🙂\"<\/p>\n","protected":false},"excerpt":{"rendered":"
Um problema comum no Frontend \u00e9 o gerenciamento e organiza\u00e7\u00e3o do c\u00f3digo e as \u00faltimas tecnologias nos \u00faltimos anos nos ajudam a resolver. Caso Tenho um c\u00f3digo que depende de mapas em v\u00e1rias telas do sistema e organizei um componente que pode ser importado em v\u00e1rios arquivos. Como esse componente tem um ciclo de desenvolvimento […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts\/1851"}],"collection":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/comments?post=1851"}],"version-history":[{"count":0,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/posts\/1851\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/media?parent=1851"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/categories?post=1851"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.milfont.org\/tech\/wp-json\/wp\/v2\/tags?post=1851"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}