Interpretador Remoto — Um novo mundo para o desenvolvedor

Um desenvolvedor, antes de tudo é um profissional. Eu gosto de definir o profissional como alguém que consegue vender uma habilidade para outra pessoa.

Quando você começa a trabalhar, um dos primeiros pensamentos que vem na sua cabeça é: "Como posso ganhar mais?". A resposta é simples, melhores as suas habilidades.

Somos uma categoria privilegiada em muitos sentidos, e ferramentas é o que não falta para um desenvolvedor hoje em dia.

Nesse artigo vamos aprender como se configura um interpretador remoto no WebStorm. Uma IDEs da JetBrains.

Interpretador Remoto

Uma IDE não existe sozinha no seu sistema, o Visual Studio ou Rider precisa do C# na maquina, o Pycharm do Python, WebStorm do npm e assim vai, muitos já instalam junto o que precisam juntos, olha essa imagem onde o WebStorm já diz que vai fazer o download o npm quando eu peço para criar um novo projeto:

O ponto aqui é, quando você vai trabalhar para uma empresa e precisa alterar muitos projetos ao mesmo tempo você começa a ter várias versões de python, npm, c# e coisas como pyenv e nvm começam a aparecer para ajudar. Também começamso a criar ambiente virtuais para instalar versões dos pacotes que preisamos somente para aquele projeto.

E bem, tudo isso funciona… O problema é que em determinado momento você vai precisar de tantas versões que muitas vezes podem nem ser suportadas mais pelo seu SO ou até mesmo encher de tanta coisa a sua máquina que torna ela inutilizável. Quem nunca instalou um pacote sem ---dev ou deu um pip install no lugar errado colocando coisas em lugares onde não deveriam, duvido que você vai lá e remove isso.

O interpretador remoto nada mais é que você ter o ambiente para aquele projeto específico rodar em outro computador, deixando sua máquina local sem absolutamente nenhuma instalação além do necessário para rodar sua IDE.

A maioria das IDEs já dão suporte para isso, o VSCode também tem esse opção. O que vai mudar é a maneira de fazer.

Como computador remoto vamos utilizar o docker, a ideia aqui é ter alguma coisa como esse. docker-compose.ymlna raiz do seu projeto:

version: "3.7"
services:
  db:
    image: postgres:10.1-alpine
  web:
    build: .
    depends_on:
      - db
    command: ["./start.sh"]

Uma uma vez que você fizer o clone do seu projeto e apontar o interpretador remoto para o container web ele será capaz de rodar testes de integração apontando para um banco de dados real que é o container db , consegue ver a mágica? Você consegue ter um ambiente com banco de dados rodando tudo localmente sem instalar nada na sua máquina.

Agora vamos a prática. Lembrando que estou escrevendo isso em 12/2022, e futuramente os prints podem ficar desatualizados, por isso é importante você entender o conceito e não apenas sair fazendo o que está escrito aqui.

Configurando o WebStorm

Se você quiser um exemplo funcional, basta olhar o repositório do meu blog, ele é feito com Gatsby e para construi-lo eu nem mesmo instalei o npm no meu MAC.

Vamos usar como exemplo a criação de um projeto usando Gatsby.

A primeira coisa que você precisa são dois arquivos no diretório que você vai criar o seu projeto:

Dockerfile:

FROM node:19-alpine3.16

RUN npm install -g gatsby-cli@5.2.0

RUN apk update
RUN apk add --update --repository https://dl-3.alpinelinux.org/alpine/edge/testing vips-tools vips-dev fftw-dev gcc g++ make libc6-compat
RUN apk add git
RUN apk add --update --no-cache python3
RUN rm -rf /var/cache/apk/*

WORKDIR /app

COPY . .

docker-compose.yml:

version: "3.8"
services:
  app:
    build: .
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    command:
      [
        "npm", "run", "develop"
      ]

Agora, basta executar . Ele vai fazer o build da imagem e pedir as informações para criar o seu projeto. O resultado final é alguma coisa assim:

Somente com Docker você conseguiu criar um projeto sem instalar absolutamente nada na sua máquina.

Agora você abre o projeto com o WebStorm, vá em settings e procure pela configuração Node.js, a opção Node interpreter estará com um alerta:

Isso, logicamente é porque você não tem o node no seu computador. Vamos criar um interpretar remoto agora.

Abra a combo do interpretador, mande adicionar um novo e escolha remoto. Na janela que for aberta, escolha Docker Compose e na combo Service escolha app que é o nome do serviço que usamos no docker.compose.yml :

Seleciona Ok e Ok de novo.

Agora vamos rodar o projeto, click em Current File:

Edit Configuration, add new e escolha npm:

Configure o necessário para rodar um projeto Gatsby como se fosse localmente:

Selecione OK e aperte Play:

E agora você tem o projeto rodando:

Tente abrir http://localhost:8000/ e você vai tomar um erro: localhost didn't send any data . E agora sim, essa é a pegadinha do interpretador remoto no caso do npm, você precisa explicitar que ele está respondendo no host 0.0.0.0 , basta configurar dessa forma o package.json :

  "scripts": {
    "develop": "gatsby develop -H 0.0.0.0",
    "start": "gatsby develop",
    "build": "gatsby build",
    "serve": "gatsby serve",
    "clean": "gatsby clean"
  },

Agora aperte play novamente e acesse o mesmo endereço:

Pronto, você tem seu projeto rodando localmente. Você pode fazer debug, rodar testes, tudo dentro do container.

Uma vez isso no git, basta outro desenvolvedor fazer o git clone , configurar o interpretador remoto e trabalhar, sem precisar instalar absolutamente nada localmente.

Link para o repositório desse post.