Forem: Michel Araujo

First look in Chrome Built-in AI [Early Preview] with Gemini Nano

Michel Araujo — Sat, 12 Oct 2024 14:47:06 +0000

In the past few weeks, I have been testing the Gemini Nano built into Google Chrome. The goal of this post is to provide some initial feedback on this new feature, which may be officially released in Chrome soon.

A little context

The main goal of integrating Gemini Nano into Google Chrome via a Web API is to promote and facilitate small AI features within web pages, without affecting performance or requiring server requests for simple responses, so, with this goal in mind, the Chrome team is working to make Gemini Nano available through an API in Chrome. This initial implementation has some limitations: it currently only works on desktops, requires a device with a GPU, and needs some available storage. To learn more about this project, you can view the official documentation here => https://developer.chrome.com/docs/ai/built-in

Note: It’s important to emphasize that this implementation is still in its early stages, and changes or improvements may be coming soon.

My test

To build my test I used a web page that I have in my lab repository build in NextJS, I used this page for a variety of tests so this project can looks like a little messy but is only for test, if you want to take a look check it out in => https://github.com/MichelAraujo/lab-playground/tree/master/my-app-next

For this test I used:

Macbook Pro M3, 18Gbs
macOS 15.0
Google Chrome Canary 131.0

My goal here was build a simple feature for understand how this built-in AI in Chrome works, for that I build a English sentence feedback, in summary works like this, I put a sentence in English and the AI give some feedback about my sentence and how I can improve it (all using AI built-in in Chrome without make any request in the server).

A little bit about my prompt config (for this test I used the Prompt API, you can learn more about in the official doc):
Note: In this built-in AI experimentation, we had access to other available APIs, such as the Summarization API, Language Detection, and a few others.

The Prompt initialization example:

const createPromptSession = async () => {
  const { available } = await ai.assistant.capabilities();

  if (available !== "no") {
    if (!session) {
      console.log('## Create session ##');

      session = await ai.assistant.create({
        systemPrompt: "you're an English teacher",
        monitor(m) {
          m.addEventListener("downloadprogress", (e) => {
            console.log(`Downloaded ${e.loaded} of ${e.total} bytes.`);
          });
        }
      });

      return session;
    }

    return session;
  }

  console.error('# Error - assistant is not available');
  return undefined;
}

The key point here is the context I provide in the prompt, like 'you're an English teacher,' to ensure that my feature delivers accurate feedback on English usage in the results.

Next, I create the prompt and send a string with context about what I want in the response, along with the user input from the page.

const streaming = await clonedSession.promptStreaming(`Give me feedback about the grammar on the following sentence in English. Sentence: ${sentence}`);
    return streaming;

Check out some feedback that AI give me with this setup, this is a simple Prompt setup but you can check the accuracy of the response, check out:

First, a simple sentence "I want to be a good guitar player!"

Second, I use the same sentence to check for a different result.

Third, a more complex sentence with little mistake:

I like this feedback!

Forth, the suggestion sentence of the previous answer:

The average quality of the answers (in my opinion) is OK, some with little mistakes or lack of context but in general is very good! Like I said, my Prompt setup can be improved too.
In the code example in the repository, I've included some prompt configuration commands that adjust the quality and context of the responses, if you'd like to check them out.

About performance

Here is the point that surprised my a lot, the performance is very good, for all of my tests I can't detect any lake of the performance or degradation in some aspects of my page. I make the tests in a page running animation and when I run the test I don't see lake of the performance in render.

Note: I tried running the same test on an old notebook I have with Windows to check the performance, but it doesn't have enough storage to run the experimental Chrome Canary with the built-in features installed. =(

For performance tests I like to show running in live, so I made a quick video that shows some tests.
For this tests I simulate 6x slowdown CPU and Slow 4g connection and the performance runs very good like you can see in the video below:
https://youtu.be/DI2pAZ-N8tw

I made some record in Devtools performance panel to see show the main thread, GPU thread, behaves when I run the AI prompts, the result was:

We can see a lot of GPU used as expected because de IA execution uses GPU.

Next, test:

The main thread seems to be running very smoothly with little JS / Render tasks that don't compromise other JS tasks execution.

Conclusion

This is a very early-stage feature, so it will see significant improvements in the future. However, it already looks very promising, and I can't wait to see how web pages will leverage it to create new features for users.
I hope this arrives for mobile too, let's wait and see.
Maybe I will share more tests.

Thanks!

INP (Interaction to Next Paint) Dicas para ajudar a melhorar essa métrica do Core Web Vitals

Michel Araujo — Mon, 15 Apr 2024 14:49:11 +0000

Esse post tem como objetivo mostrar algumas técnicas simples que podem ser usadas em aplicações reais e ajudar você a da os primeiros passos na melhora do INP, os exemplos aqui em termos de codificação e funcionalidades são realmente simples mas o ideal é fazer o exercício de pegar o que achar interessante aqui entender mais a fundo e abstrair para o seu cenário em questão.

O que o INP tenta resolver?

Primeiro é importante de fato entender o que é a métrica Interaction to Next Paint (INP), qual problema ela tenta resolver (evidenciar) e se quiser entender um pouco mais do histórico seria bom pesquisar porque ela substituiu o FID como métrica do Core Web Vitals.
Dando um resumo inicial o INP tenta medir a responsividade que uma página web tem metrificando o tempo que leva para o navegador renderizar algo na tela depois de alguma interação do usuário, essa interação pode ser click, tab, eventos de teclado, mouse e etc, com base nesse valor (em MS) podemos medir seguindo as definições do Google se um interação tem uma boa, média ou pobre responsividade (INP).

Para a medição do Core Web Vitals em si que é o valor mostrado na página do pagespeed, por exemplo:

Cada interação na sua página vai gerar um valor em MS que conta para essa métrica, usuários que usam o Chrome o CrUX (Chrome User Experience Report) vai pegar sempre o maior valor para contar como a métrica INP daquela sessão, exemplo:
Se o usuário clicar em dois botões na página e essas interações ficarem em torno de 30ms e depois na mesma sessão o usuário clicar em um link e a interação lever 200ms é os 200 que conta, que é enviado pelo CrUX.
Tem algumas regrinhas para remover outliers e gera um número baseado no 75 percentil com base nos acessos de outros usuários, mas em resumo é mais ou menos assim que funciona.

Para entender melhor como esses dados são coletados aconcelho da uma olhada nesse post: https://web.dev/articles/vitals#measure-report

Ponto importante: Vale ressaltar aqui que essas métricas do Web Vitals não são feitas de forma aleatórias pelo Google, nem para “ferrar” os donos de site mas é um meio de metrificar, evidenciar problemas nas páginas web que impactam diretamente a experiência do usuário e que muitas vezes passam despercebidas, então sempre tenha em mente que as métricas do Web Vitals no fim de dia é para ajudar na UX da sua página.

Recomendo entender um pouco como o browser funciona

Para entender mais facilmente como identificar os pontos de gargalos e entender como as técnicas mostradas aqui ajudam é recomendado ter uma noção básica de como o navegador funciona, eu gosto bastante desse vídeo ele dá uma boa introdução sobre o event loop e como o JS é executado na página:

Tem também a transcrição do vídeo em formato de post:
https://www.andreaverlicchi.eu/blog/jake-archibald-in-the-loop-jsconf-asia-talk-transposed/

O problema

Beleza, agora temos uma noção um pouco melhor do que é o INP e de como esses dados são coletados, agora vamos entender mais a fundo o problema que essa métrica tenta evidenciar. Para exemplificar de uma forma mais didática eu criei uma página de exemplo que tem apenas uma interação (click em um botão para mostrar uma imagem) mas essa interação está com uma podre responsividade (problema de INP).

Obs: O objetivo aqui não é focar no código fonte ou boas práticas de programação mas sim nas técnicas para melhora do INP.

A página de exemplo está em Next JS 14.1.4 e React 18, a estrutura inicial foi criada usando os comando CLI do próprio Next JS, para esse post foi escolhida essas tecnologias apenas pela facilidade do setup inicial.
Todos os testes realizados são simulando um Samsung Galaxy S8 com 4x CPU slowdown pelo DevTools.

O código do exemplo pode ser encontrado aqui.

O exemplo

Na nossa página de exemplo temos um botão de click que mostra uma imagem de gato (claro!) e por baixo dos panos é executado algumas outras tasks JS que no mundo real pode ser comparada com acesso a uma API, processar alguma regra de negócio, envia uma tag de Analytics e etc.
Inicialmente ao clicar no botão de “So Something” temos um INP de 2 a 3 segundos!!
Lembrando que o ideal segundo a documentação do Google é ficar abaixo de 200 ms.

Exemplo em video:

Beleza.. Sabemos que temos um problema, agora vamos começar a entender a causa e como resolver. Para mostrar no console os MS de cada interação na página igual mostrado no vídeo estamos usando esse código:

(()=>{let o=globalThis;return void 0===o.winp&&(o.winp=0,new PerformanceObserver(n=>{for(let e of n.getEntries()){if(!e.interactionId)continue;o.winp=Math.max(e.duration,o.winp);let r=o=>o<=200?"color: green":o<=500?"color: yellow":"color: red";console.log(`%c[Interaction: ${e.name.padEnd(12)}] %cDuration: %c${e.duration}`,"color: grey; font-family: Consolas,monospace","",r(e.duration))}}).observe({type:"event",durationThreshold:0,buffered:!0})),o.winp})();


performance.interactionCount;

Basta colar no console do navegador e começar a interagir na página, esse código mostra os MS de cada interação e seu tipo (click, keyup e etc).

Sabendo de tudo isso a primeira coisa que vamos fazer é gravar essas interações usando a aba de performance do DevTools, no momento temos o seguinte resultado:

Cada coluna desta é uma task JS que foi disparada pela iteração feita no botão, se observarmos com atenção podemos ver que cada task JS desta está relacionada a um evento de click, se passar o mouse em cima da task vamos ver o tempo que a mesma levou para executar, vale lembrar que esse é o tempo que o event loop fica preso executando essa task até poder fazer outra coisa como entrar no passo de render (pintar algo na tela). Um pouco mais acima temos a parte das interações “Interactions” essa parte mostra o tempo que uma interação demorou desde do seu início até seu fim e quais task JS afetou essa interação ou seja, por aqui também podemos medir o tempo do INP e de quebra entender quais tasks são responsáveis pelo delay na interação, veja esse exemplo, essa interação demorou 2.55 segundos (tempo do INP).

Nesse exemplo, olhando para esse relatório gravado pelo DevTools já dá para saber que apenas uma task JS está bloqueando toda a main thread, mas o que ela faz?
Olhando com mais atenção a Call Tree podemos ver que lá no final temos uma função de onClick sendo executada e depois 3 tasks grandes de uns 900 ms cada sendo executadas de forma sequencial (indício de problema).

Obs o INP é calculado no próximo render do browser que na gravação do DevTools é a parte verde que geralmente é o “Paint” ou “Commit” que significa que o browser renderizou algo na tela, no nosso exemplo se dermos um zoom nessa gravação podemos achar o Commit lá depois de toda essa task grande JS ser executada, esse é um problema de fato para o INP

Se você tiver acesso ao código fonte da aplicação que estiver analisando e se for em frameworks como o Next JS geralmente tem como você executar em modo de desenvolvimento, fazendo essa mesma gravação no DevTools em mode de desenvolvimento pode ser que fique mais claro o nome de cada função que está sendo executada e facilite na hora de achar o problema, veja a próxima imagem, vale lembrar também que testando a aplicação em modo de desenvolvimento pode ser que a performance fique pior ainda e o resultado mais distante de produção.

O que sabemos até agora..
Tem uma função de onClick que realiza 3 tarefas pesadas dentro dela e compromete o next paint do browser consequentemente o INP.
Olhando para o código da nossa função temos isso:

const doSomething = () => {
    const rTask1 = task1();
    const rTask2 = task2();
    const rTask3 = task3();

    // Change state
    setShowImage(!showImage);
  };

A função doSomething é a nossa função de handler do click e de cara podemos ver as 3 funções que estão sendo chamadas de forma sequencial seguido de um setState.

Tendo esse pequeno código em mente vou da a principal dica para melhorar o INP:
Sempre priorize o render (o feedback para o usuário) depois de alguma interação.

Todas as técnicas mostradas a seguir foram pensadas seguindo essa dica.

A técnica do yielding

A primeira vez que eu vi essa técnica foi lento esse post que por sinal recomendo muito.
Tentando explicar de forma resumida, essa técnica consiste em quebrar task JS grandes em menores, se lembrarmos um pouco de como o browser funciona o pipeline de render é executado pelo event loop entre a execução de task JS, o event loop pode executar centenas de task JS antes de decidir fazer um render, quebrando tasks grandes em menores podemos dizer então que estamos dando mais oportunidade para o browser fazer o render de algo na tela, lembrando da dica de sempre priorizar o render já dá para perceber como essa técnica ajuda, vamos ter tasks menores e o browser pode fazer o render mais vezes.
Para implementar essa técnica basta apenas criar uma função assim:

function yieldToMain () {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

E chamar ela onde você tem oportunidade de quebrar a task em execuções menores.

Para maiores informações sobre essa técnica vale dá uma olhada aqui

A primeira alteração que vamos fazer no código então é a seguinte, vamos chamar a função de yieldToMain() depois de cada task que temos na função doSomething, o código ficou assim:

Gravando novamente as interações já dá para notar que não temos mais aquela task gigante mas sim apenas 3 task grande =D e monitorando as interações da para perceber uma pequena melhoria o que antes estava em torno de 3 segundos agora foi para 1 segundo, ainda é muito ruim mas vamos continuar as alterações…

Continuando as melhorias pensando na dica de sempre priorizar o render vamos supor que essas 3 taks sejam coisas de background e o setState não precise esperar o retorno dessas função para ser executado então podemos priorizar totalmente o setState, o código fica assim:

const doSomething = async () => {
    //Change state
    setShowImage(!showImage);

    await yieldToMain();

    const rTask1 = task1();
    await yieldToMain();

    const rTask2 = task2();
    await yieldToMain();

    const rTask3 = task3();                                                                                             });

Fazendo isso podemos ver mais alguma melhora no resultado dos testes, olhando novamente o resultado das interações e as gravações temos o seguinte resultado:

Aqui vem um pouco muito importante, mesmo com esse resultado bom para o INP não quer dizer que já temos a melhor UX, o browser aqui pode ter considerado o change do botão, borda, pequena mudança de cor na hora do click mas a imagem em si que queremos mostrar ainda vai ter o delay de algum tempo, temos que ficar espertos com isso se nosso objetivo é melhorar a UX como um todo.

O ponto chave dessa alteração é esse
Agora temos uma task menor que provavelmente já está processando o setState (linha verde no report gravado, próxima imagem) depois tem uma quebra com o yieldToMain que foi acrescentado depois do setState no código (repare no código acima) dando oportunidade para o browser fazer o render (seta vermelha na imagem).

Para esse caso as interações já estariam aprovadas < 200 ms, mas como no mundo real nem tudo são flores ainda temos alguns casos que podem degradar nosso INP. O primeiro deles é se nosso render (setState) depender do retorno de alguma função dessa, nesse cenário a solução é até simples, podemos colocar um loading para fazer o browser executar o next render depois de uma interação o mais rápido possível dando o feedback para o usuário de que algo está sendo processado, fazendo essa modificação no nosso código fica assim:

Nesse caso teoricamente não é para ter grandes modificações nas medições de performance, tudo é para continuar verde.

Note que o setState que faz a alteração da imagem de fato voltou para depois que as task são executadas.

Resultado em video:

Cenario do usuarios impacientes

Novamente o mundo real é mais cruel do que a gente testando em laboratório, vamos supor que nossos usuários são impacientes e ficam clicando no botão antes que de tempo das task JS realmente terminar de fato, nesse cenário ainda vamos ter um problema de INP sério, veja a reprodução desse cenário:

Nesse vídeo estou clicando no botão de doSomething várias vezes

Lembrando que não foi feita mais nem uma alteração de código depois dos últimos testes o que mudou apenas foi o comportamento do usuário (nesse caso a forma que estamos testando)

Nesse cenário o que está acontecendo é a próxima interação que é feita está iniciando enquanto o browser ainda não terminou de processar umas das task grandes, podemos ver isso na gravação:

Perceba as interações iniciando no meio da task.

PAUSA NOS CENÁRIOS - Entendendo um pouco mais do INP

Para o cálculo do valor total do INP é considerado 3 sub métricas que são:

Input Delay
Processing time
Presentation delay

Juntando o valor em MS dessas 3 sub métricas temos o valor total do INP, exemplo:

Input Delay - 30 ms
Processing time - 50 ms
Presentation delay - 10 ms

Valor do INP é de 90 MS

Prestar atenção nessas sub métricas pode nos ajudar a identificar onde está o gargalo de algum ponto.

Voltando para o exemplo..

Podemos ver que o que mais está demorando é o presentation delay ou seja, a task está pronto para o browser renderizar mas o browser estava ocupado executando as outras task e levou 721 ms até achar um tempo para renderizar.
Em outras casos é o input delay que demora mais ou seja o browser está ocupado processando alguma task que não conseguiu nem iniciar a nova task referente a interação, por todos esses motivos que é importante ter em mente sempre tentar ter tasks JS menores possível.

Para melhorar esse cenário podemos fazer algumas alterações no código e usar algumas outras técnicas como o requestAnimatedFrame para sinalizar para o browser que no próximo frame teremos alguma renderização na tela e que aquela task JS vai ter alguma renderização.
doc

Podemos também deixar as task async para as mesmas serem executadas em paralelo reduzindo o tempo total de processamento e evitando o “choque” de entrar uma nova task de interação enquanto ainda tem coisa processando.

Com todas essas alterações chegamos na melhor otimização possível até o momento, o código ficou assim:

const doSomething = async () => {
    // Show loading
    window.requestAnimationFrame(() => {
      setPageState({ ...pageState, loading: true });
    });
    await yieldToMain();

    const promiseTask1 = task1();
    const promiseTask2 = task2();
    const promiseTask3 = task3();

    await promiseTask1;
    await yieldToMain();

    await promiseTask2;
    await yieldToMain();

    await promiseTask3;
    await yieldToMain();

    // Hide loading and show image
    window.requestAnimationFrame(() => {
      setPageState({ showImage: !pageState.showImage, loading: false });
    });
  };

Execução ficou assim:

A imagem acima foi feita simulando todos os cenários de um simples clique e de ficar clicando múltiplas vezes, sendo assim podemos observar que apesar de termos uma boa melhora do início do post que a média ficava em torno de 2 a 3 segundo ainda temos alguns gargalos para melhorar.
Até o momento a gente só trabalhou no gerenciamento das tasks e ajudando o browser a entender que algo deve ser renderizado na tela, as funções que estão lenta de propósito até o momento ainda continuam lentas (não foram alteradas), o objetivo até aqui foi mostrar que mesmo que temos funções difíceis de otimizar apenas gerenciando bem as task podemos conseguir melhorar consideravelmente a média do INP mas para melhorar de fato temos que foca em sempre fazer as tasks menores possíveis, para exemplificar isso vamos mexer agora nas tasks de exemplos que estavam lenta de propósito (task1, task2, task3), vamos criar um novo cenário em que temos mais tasks porém com tempo de execução menor, o código vai fica assim:

const doSomething = async () => {
    window.requestAnimationFrame(() => {
      setPageState({ ...pageState, loading: true });
    });

    const tasks = [];

    for (let i = 0; i < 10; i++) {
      const rTaskPromise = task1();
      tasks.push(rTaskPromise);
      await yieldToMain();
    }

    await Promise.all(tasks);

    window.requestAnimationFrame(() => {
      setPageState({ showImage: !pageState.showImage, loading: false });
    });
  };

  const manageImage = () => {
    if (pageState.showImage) {
      return <img
        src="http://localhost:3000/cat_img.webp"
        width={612}
        height={408}
        alt="Image of the a Cat"
        decoding="async"
      />
    }

    if (pageState.loading) {
      return <img
        src="http://localhost:3000/loading.webp"
        width={300}
        height={300}
        alt="Image of the loading"
        decoding="async"
      />
    }
  };

  return (
    <>
      <button onClick={doSomething} title="Show or hide image button">Do Something</button>
      <br />
      {manageImage()}
    </>
  );

Coloquei o código mais completo dessa vez para vocês terem uma noção do que está acontecendo no render também.

O resultado do report ficou assim:

Com esse report podemos observar:

O INP foi super rápido, ficou nos 29 ms ou seja está verde.
O loading está sendo mostrado o mais rápido possível.
Agora temos várias tasks pequenas (simulando a quebra daquelas task grande que teríamos antes), assim se o browser precisar tem mais oportunidade para fazer um render no meio dessas tasks.
Por fim temos o render da imagem em si.

Se a gente simular um cenário de stress agora (vários clicks seguidos) vamos observar que tem bem menos engasgo do que antes, isso é onde as tasks menores ajudam!

Bônus - mostrar e sumir com um elemento

Minha ideia era parar o post por aqui, mas fazendo esses testes com esse exemplo simples apareceu um cenário muito interessante que dependendo da sua funcionalidade pode surgir na vida real também.
Se você já não reparou observe no último report que temos um step de commit que está tomando bastante tempo, isso pode ser um problema principalmente para o cenário de stress, como em task JS uma nova interação pode surgir e o browser está executando essa task de commit longa, exemplo:

Como você já deve ter entendido isso é ruim para o INP.

Nesse meu exemplo simples isso aconteceu pelo modo que estou fazendo o elemento de imagem (tag img) ser removida e incluída no DOM toda hora que interagimos com o botão, isso força o browser fazer todo o processo de layout, paint, render em toda interação, para melhorar isso em vez de ficar adicionando e removendo o elemento do DOM vou trabalhar com opacidade e animação, assim o browser só vai executar os passos realmente necessários para a animação mas o elemento em si vai continuar na árvore do DOM e Layout, vamos ver como fica:

O report agora ficou assim, podemos notar que não tem mais aquela task de commit grande, tudo parece fluir muito melhor agora com todas tasks pequenas!

Conclusão

Espero que algumas dessas dicas ajude alguém nas suas otimizações na vida real, a ideia do post foi realmente passar o contexto e ajudar nos primeiros passos dessa jornada de otimização, como prática faça seus próprios testes, tente criar exemplo usando as dicas desse post, depois pode comentar se o resultado foi parecido com os dos meus teste.
Acredito que nos próximos meses/ano vai ter muito mais coisa boa vindo ai que pode ajudar ainda mais, muita feature nova nos browser que hoje só funciona no Chrome (por isso nem citei aqui), WebAPIs que vão ajudar a usar menos JS na página e etc.

O código completo deste exemplo vai está nesse github

Como debugar nossas aplicações em NodeJS com mais eficiência!

Michel Araujo — Sat, 01 Aug 2020 15:59:20 +0000

Neste post vou falar um pouco de como podemos usar o Chrome Devtools para debugar nossas aplicações em NodeJS e como podemos usar os logs a o nosso favor.

O que vamos abordar neste post:

Fazendo debug de aplicações em NodeJS usando o Chrome Devtools
Agora vamos falar um pouco sobre Logs!
Lembrando de funções básicas de log
Boas ferramentas!
Dicas

Fazendo debug de aplicações em NodeJS usando o Chrome Devtools

A partir da versão 6.3.0 do NodeJS temos disponível a flag — inspect que disponibiliza para nós uma porta específica para debug via conexão socket, isso possibilita que nossas aplicações em NodeJS sejam analisadas usando o Chrome Devtools e todos seus recursos mais legais. Para saber mais sobre esse protocolo e como podemos usar ele não só com o Chrome Devtools sugiro que leiam o documento Chrome Debugging Protocol Viewer.

Vamos da uma olhada como isso funciona de uma forma simples com alguns exemplos.

O código a seguir simplesmente calcula quantos anos você estaria a 10 anos atrás e quantos anos você vai estar daqui a 10 anos.

O código está separado em 3 arquivos, future.js, past.js e index.js, segue a baixo:

future.js

const future = (age, gap) => {
  return `In ${gap} years you will be ${Number(age)+gap}<br/>`;
}

module.exports = future;

past.js

const past = (age, gap) => {
  return `${gap} years ago you were ${Number(age)-gap}<br/>`;
};

module.exports = past;

index.js

const express = require('express');
const past = require('./past');
const future = require('./future');

const app = express();

app.get('/:age', (req, res) => {
  res.send(past(req.params.age, 10) + future(req.params.age, 10));
});

app.listen(3000);

Executando esse app e acessando a url: http://localhost:3000/30 temos o seguinte resultado:

Podemos ver que a um resultado não esperado “NaN”, vamos usar o Chrome Devtools para tentar achar o problema. Para fazermos isso temos que iniciar nosso app com a flag — inspect ficando assim:

$ node — inspect index.js

Podemos notar que na saída do console vamos ter algo parecido com:

Debugger listening on ws://127.0.0.1:9229/60b72ae3–68ce-4123-bab4-cf8d2e180df6
For help, see: https://nodejs.org/en/docs/inspector

Isso quer dizer que nosso debug está funcionando e pronto para ser conectado a um cliente via socket com essa url:

ws://127.0.0.1:9229/60b72ae3–68ce-4123-bab4-cf8d2e180df6

Para se conectar a ele vamos abrir uma nova aba do Chrome e digitar o seguinte endereço: "chrome://inspect", se tudo der certo já podemos ver que o Devtools encontrou nosso app.

Para iniciar nosso Devtools vamos clicar em “Open dedicated DevTools for Node” e então podemos ver nosso Devtools aberto:

Vamos focar agora em descobrir o que está de errado no nosso app que está retornando o valor “NaN”, de início vamos colocar um breakpoint na linha 8 e fazer um novo request para nosso app na url "http://localhost:3000/30", no navegador a página deve se manter esperando pelo nosso server já que temos um breakpoint interrompendo a continuidade da execução, no nosso devtools podemos ver que a linha com o breakpoint ficou destacada:

Podemos notar algumas coisas interessantes aqui, uma delas é que se passamos o mouse sobre a variável req.params podemos ver os valores que estão chegando na nossa request, com base nisso já podemos descobrir a causa no nosso problema mas vamos continuar dando uma olhada.. Na coluna à direita podemos ver toda call stack que foi chamada até o momento, e no início da coluna temos alguns controles que podem ser muito úteis no nosso debug, vamos clicar no terceiro botão de controle para seguir um passo à frente na execução do nosso programa.

Feito isso vamos entrar no próximo passo da execução do nosso programa que nesse caso é a função past como podemos ver na imagem a seguir:

Passando o mouse sobre as variáveis/parâmetros podemos conferir se todos os valores estão chegando corretamente, uma outra forma de ver isso é olhando na coluna à direita em baixo da Call Stack temos uma parte chamada Scope -> Local aí podemos ver todas as variáveis do escopo local no momento e seus respectivos valores, veja a imagem abaixo:

Certo, conferindo que aqui está tudo ok vamos voltar para a função principal no arquivo index clicando no quarto botão de controle (setinha para cima).

Voltando para o arquivo index podemos notar que a função future na linha 8 agora está destacada, isso quer dizer que ela será a próxima na execução, então se a gente clicar no terceiro botão de controle novamente indo para a próxima execução do nosso programa vamos cair no arquivo future.js na função future como mostrado na imagem abaixo:

Passando o mouse pelas variáveis/parâmetros podemos notar que o parâmetro age está com o valor undefined (podemos ver também no Scope -> Local na coluna a direita), ou seja ele está recebendo um valor undefined mas o problema não está nesta função, vamos voltar novamente para função principal no arquivo index.js clicando no quarto botão de controle (setinha para cima).

No arquivo index.js passando o mouse pelo parâmetro que é passado para a função future podemos notar que realmente está undefined e se observarmos com mais atenção podemos ver que está errada por não existir o parâmetro future req.params.future o correto seria req.params.age, podemos editar isso direto no devtools ou na sua IDE de preferência. Fazendo essa correção vamos remover o breakpoint e clicar no botão azul (primeiro botão de controle) para dar continuidade na execução do nosso programa. Feito isso podemos notar que no navegador os valores já vão estar corretos. Pronto! Problema resolvido.

O exemplo mostrado aqui é bem simples mas existem diversos outros recursos no Devtools que pode nos ajudar a debugar nossa aplicação de uma forma bem completa como o uso de memória e cpu, como descobrir gargalos de memória, como podemos aproveitar a Call Stack para entender como nossa aplicação está funcionando e etc.

Para um exemplo mais aprofundado pode da uma olhada nesse post Finding And Fixing Node.js Memory Leaks: A Practical Guide

Podemos usar esse recurso do — inspect para debugar aplicações que estão rodando em container também, para saber mais sugiro dar uma olhada nesse post How to Debug a Node.js app in a Docker Container

Podemos também usar esse recurso em produção mas isso é extremamente perigoso já que abre uma porta direto com sua aplicação e todo seu contexto, se realmente for necessario usar isso em produção sugiro que siga essa recomendação Node Doc, remote debugging scenarios

Algumas curiosidades de como tudo isso funciona

Tudo isso é possível graças a engine JavaScript V8, quando executamos o node com a flag — inspect a engine V8 abre uma porta que aceita conexão WebSocket, uma vez que a conexão é feita comandos em formato de pacotes JSON são enviados entre o Inspector e o cliente.
O Inspector WebSocket é escrito em C e roda em uma thread separada assim quando o processo é pausado (breakpoint) o inspector continua funcionando.
Quando um breakpoint é colocado o event loop é pausado e toda informação (Call Stack, Variáveis) daquele momento são enviadas para o cliente, cada interação com os botões de controle é despausado o event loop e pausado novamente atualizando essas informações no cliente.

Agora vamos falar um pouco sobre Logs!

Logs no STDOUT

Quando estamos executando nosso programa e algo dá errado um log de erro é mostrado no nosso STDOUT como esse:

Mas se precisamos ver um trace maior do que é mostrada por padrão? Para isso podemos usar a flag -stack-trace-limit=21 para alterar o limite de trace da saída para um valor que for melhor para nós, exemplo:

Uso da env DEBUG

Outro recurso legal que podemos aproveitar é usar o máximo o debug do node, por exemplo, podemos habilitar o debug do node para nos mostrar todo log de execução que está acontecendo no express, para isso vamos executar o node com a flag DEBUG=express:*.

DEBUG=express:* node index.js

Como a imagem acima nos mostra essas informações podem ser úteis para uma investigação mais aprofundada do que está acontecendo na aplicação.

Se eu quiser saber o log só do express router por exemplo:

DEBUG=express:router node index.js

Para mostra tudo:

DEBUG=* node index.js

Lembrando de funções básicas de log

console.log(arguments): printa algo na saída padrão
console.error(arguments): printa algo na saída de erro
console.trace(label): printa um trace da execução
console.time(label) / console.timeEnd(label): essa combinação pode ser usada para mostrar o tempo de execução de uma parte do código.
console.dir(object): printa a estrutura de um objeto na saída padrão

Para aproveitar a o máximo todo o poder que os logs podem fornecer nos momentos em que mais precisamos não podemos deixar de lado os bons padrões para se ter em um log, já existem vários desses padrões muito bem definidos na comunidade e um que recomendo a análise é a do Twelve-Factor App Logs.

Dicas

Não se esqueça dos testes

Os testes podem ajudar a ampliar o entendimento da sua aplicação facilitando assim achar o motivo de um possível bug, lembre sempre de olhar seus testes em um processo de debug e melhorar ainda escrever o teste para a caso em questão ajudando assim que o mesmo problema não retornar futuramente.

Aproveite a evn NODE_DEBUG em seu localhost

Você pode usar essa env para um “scan” do que está acontecendo na sua aplicação em tempo de execução separadamente por módulos do node por exemplo, module, http e etc.
Para mais informações: node_debug

Tome cuidado com a forma que você está fazendo seus logs

Para finalizar gostaria de recomendar uma palestra que mostra o impacto em desempenho que os logs podem ter na sua aplicação em especial quando usamos alguma lib de log, Node Summit 2016 — The Cost of Logging.

Boas ferramentas!

stackup: É um módulo do npm que enriquece as informações de erro quando algo dá errado, ele é bem útil principalmente quando algo dá erro em chamada async. Saiba mais em: https://www.npmjs.com/package/stackup

Conclusão

Bom espero que esse post possa te auxiliar em fazer cada vez mais debugs de forma eficiente ajudando a solucionar os problema que nos deparamos no dia a dia sem bater muita a cabeça.

Fonts:

Stay hungry Stay foolish!

Conheça um pouco mais sobre o sistema de módulos em Node.JS e NPM

Michel Araujo — Sat, 25 Jul 2020 15:41:41 +0000

O objetivo desse post é mostrar de uma maneira objetiva como algumas coisas funcionam no sistema de módulos do Node.JS e recursos que podem ser úteis no dia a dia.

O que vamos abordar neste artigo:

Começando do começo! (Comandos basicos do NPM)
Está rodando NPM com sudo ? Saiba como ajustar isso.
Como funciona a versão dos módulos
Para que serve o caracter “^” ?
Como funciona exports e require em NodeJS
NPM Scripts
Como configurar um registry Scope
Boas ferramentas!

Começando do começo!

Vamos apresentar aqui algumas configurações básicas do NPM.
O comando “npm config” pode ser usado para alterar as configurações do seu npm permanentemente, por exemplo para configurar um nome de autor podemos usar o seguinte comando:

npm config set init.author.name "<name here>"

Obs: Esse nome de autor será usado quando executamos o comando “npm init”

Você pode listar todas as configurações atuais que você fez usando o comando “npm config ls” ou visualizar todas as configurações inclusive as que já vem por padrão com o comando “npm config ls -l”.

Para visualizar a documentação completa das configurações do NPM acesse npm-config page, sabendo usar essas configurações ao nosso favor podemos aproveitar muito mais alguns recursos do NPM como cache, diferentes locais de instalação de dependências ou usar um registry customizado, ao longo deste post vamos ver mais a fundo algumas dessas config.

Comandos basicos do NPM

npm install : Baixa um módulo para o diretório node_modules sem salvar permanentemente, ou seja, se o diretório node_modules for deletado no próximo npm install essa módulo não será baixado.
npm install --save : Baixa um módulo no diretório node_modules e registra a versão baixada no arquivo package.json assim no próximo npm install o módulo será baixado novamente, atualiza o package-lock quando há alguma atualização de versão.
npm install --save-dev : Baixa um módulo no diretório node_modules e registra no package.json como uma dependência de desenvolvimento.
npm install --production: Baixa todas as dependências menos as que são instaladas com a flag --save-dev (dependências de desenvolvimento)
npm ci: Baixa todas as dependência seguindo exatamente as versões que estão no arquivo package-lock não fazendo nem uma alteração no mesmo.
npm ls: Vai retornar toda a árvore de dependência de produção e desenvolvimento, pode ser muito útil para achar sub-dependências ou dependências que não deveriam existir.
npm audit: Faz uma varredura nas suas dependências procurando por versões que podem possuir algum tipo de vulnerabilidade, no final retorna um relatório com cada descoberta e sua criticidade.
npm outdated: Mostra todas as dependências que tem atualização disponível.

Está rodando NPM com sudo ? Saiba como ajustar isso.

Você já se deparou com a necessidade de executar algum comando do npm com sudo ? Ou todos os comandos? Se sim isso acontece provavelmente porque o usuário que você está executando o comando não tem permissão para acessar o diretório que contém os módulos globais ou locais do npm.
Existem algumas maneiras de ajustar isso, vou mostrar aqui a que eu mais gosto =).

Primeiro vamos executar o comando “npm config get prefix”, com esse comando podemos ver onde estão sendo instalados nossos módulos, provavelmente estão dentro de /usr/local/.
O que vamos fazer é trocar o local onde os módulos do npm são instalados criando um diretório para isso.
Vamos criar um diretório na nossa pasta home:

mkdir ~/npm-global

Depois vamos fazer com que nosso diretório central do npm seja esse que criamos usando o comando:

npm config set prefix ~/npm-global

Vamos precisar adicionar ao nosso PATH do sistema esse nosso diretório para conseguirmos chamar nossas libs pelo terminal sem problemas.

export PATH=$PATH:~/npm-global/bin
source ~/.profile

Pronto, para conferir se a configuração está ok você pode executar o comando “npm config get prefix” e visualizar se é o seu diretório que retorna.
Se você já tiver algum projeto que esteja usando sudo para executar os comandos recomendo que remova o diretório node_modules e execute npm install novamente, assim tudo deverá funcionar sem sudo agora.

Como funciona a versão dos módulos

Os módulos do npm segue um padrão de versionamento chamado SemVer (Semantic Versioning), esse padrão consiste basicamente de 3 números sendo eles MAJOR, MINOR e PATCH separados por ponto, ex: 2.3.14. (Como se pode notar o número de cada posição da versão corresponde a Major.Minor.Patch).

PATCH: Está relacionado a qualquer alteração feita que não quebra a funcionalidade já existente e não adiciona uma funcionalidade nova, o melhor exemplo para isso é correção de bug.
Vamos imaginar que temos um módulo na versão 1.0.0, fizemos uma correção de bug e adicionamos uma documentação, a próxima versão será 1.0.1.

MINOR: Seu valor é aumentado quando adicionamos uma nova funcionalidade que não quebra as já existentes, mantendo a compatibilidade.
Voltando a o nosso módulo de exemplo vamos imaginar que adicionamos uma nova função para retorna uma lista de produtos, não altera as já existentes apenas faz algo novo então a próxima versão do nosso módulo será 1.1.0.

MAJOR: Está relacionado a qualquer alteração que tenha uma quebra de compatibilidade, por exemplo a alteração da interface de uma função, alteração no padrão de retorno de uma função já existente e etc.
Voltando a o nosso módulo imaginário digamos que vamos alterar nossa função que retorna a lista de produtos trocando seu retorno de Array para Json, sendo assim a próxima versão do nosso módulo será 2.0.0.

Observe que cada incremento na categoria maior reseta a menor, se fizemos um incremento no MINOR o PATCH é resetado, se fizemos um incremento no MAJOR, o MINOR e o PATCH é resetado.

Se quiser entender um pouco mais a fundo sobre esse padrão de versionamento recomendo que leia Semantic Versioning Web Page.

Podemos fazer essas alterações de versão alterando diretamente nosso arquivo package.json ou usando os comando do npm:

npm version patch // Incrementa o patch
npm version minor // Incrementa o minor
npm version major // Incrementa o major

Ou setar já tudo de uma vez com:

npm version 2.0.0

Para ver a versão do seu módulo como também a do node, npm, v8 é só executar o comando:

npm version

Para que serve o caracter “^” ?

Quando executamos o comando “npm install --save ” por padrão a versão do módulo é adicionado a o nosso package.json com o caractere “^” na frente, ex: express": "^4.17.1".
Esse caractere indica que qualquer alteração de PATCH que houver vai ser adicionada automaticamente, por exemplo vamos supor que foi feito um novo incremento no nível PATCH do express “4.17.2”, quando a gente executar o comando “npm install” novamente esse incremento já vai ser adicionado automaticamente. Segue a mesma regra para toda árvore de dependência, ou seja toda dependência e sub-dependência do express vai seguir essa mesma regra.
Esse comportamento por padrão permite que nossa aplicação receba um bug fixes sem mesmo a gente saber, por outro lado isso requer um certo nível de confiança sobre o módulo que estamos consumindo, se você não quiser esse comportamento pode simplesmente editar manualmente o arquivo package.json removendo o caractere “^”.
Ou se sua aplicação/módulo está em um nível estável e você quer garantir que nem uma alteração não conhecida de dependência seja feita, podemos desabilitar a atualização do arquivo package-lock.json, sendo assim todo “npm install” vai pegar as dependências com a versão fixada do package-lock que serve como um snapshot das dependências, sem fazer qualquer atualização de versão, para fazer isso é só executar o comando:

npm config set package-lock false

Obs: com essa configuração não vai ser gerado arquivo package-lock para novos projetos/módulos, fique atento com isso!

Esse recurso pode ser muito útil se seu software passa por auditoria ou um processo mais rigoroso referente a atualização de dependência, com o snapshot do package-lock fica mais fácil controlar as versões e comprovar isso.

Como podemos ver o package-lock.json funciona como um snapshot de dependências e sub-dependências, ele é nada mais que uma árvore contendo o registro de versões das dependências e das dependências das dependências que são usadas na sua aplicação/módulo, sugiro que você abra um arquivo package-lock.json e dê uma olhada com atenção isso pode clarear mais as coisas.
Para mais informações Documentação npm package-lock.json.

Como funciona exports e require em NodeJS

Inicialmente para deixar claro todo arquivo que contenha código JS é considerado um módulo no NodeJS, contendo variáveis, funções exportadas ou não.

Quando fazemos alguma chamada (require) a um módulo em NodeJS o mesmo é encapsulado (wrapped) por uma função, essa função consiste em:

( function (exports, require, module, __filename, __dirname) {
/* código do modulo aqui */
})

Como podemos ver essa função contém 5 parâmetros cada uma responsável por armazenar diferentes informações sobre o módulo que está sendo exportado.
Para facilitar o entendimento de cada um desses parâmetros vamos criar um módulo teste chamado myModule.js e ver como isso funciona na prática.

O código do nosso módulo inicialmente vai ser o seguinte:

console.log('Exports => ', exports);
console.log('Require => ', require);
console.log('Module => ', module);
console.log('Filename => ', __filename);
console.log('Dirname => ', __dirname);

Quando executamos esse script (módulo) vamos ter o valor referente a cada parâmetro da função wrapped citada acima.
Vamos executar o comando:

node myModule.js

E o resultado será o seguinte:

Exports =>  {}
Require =>  [Function: require] {
  resolve: [Function: resolve] { paths: [Function: paths] },
  main: Module {
    id: '.',
    path: '/home/michel/Workspace/lab/examples_posts/modules_npm',
    exports: {},
    parent: null,
    filename: '/home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js',
    loaded: false,
    children: [],
    paths: [
      '/home/michel/Workspace/lab/examples_posts/modules_npm/node_modules',
      '/home/michel/Workspace/lab/examples_posts/node_modules',
      '/home/michel/Workspace/lab/node_modules',
      '/home/michel/Workspace/node_modules',
      '/home/michel/node_modules',
      '/home/node_modules',
      '/node_modules'
    ]
  },
  extensions: [Object: null prototype] {
    '.js': [Function],
    '.json': [Function],
    '.node': [Function]
  },
  cache: [Object: null prototype] {
    '/home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js': Module {
      id: '.',
      path: '/home/michel/Workspace/lab/examples_posts/modules_npm',
      exports: {},
      parent: null,
      filename: '/home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js',
      loaded: false,
      children: [],
      paths: [Array]
    }
  }
}
Module =>  Module {
  id: '.',
  path: '/home/michel/Workspace/lab/examples_posts/modules_npm',
  exports: {},
  parent: null,
  filename: '/home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js',
  loaded: false,
  children: [],
  paths: [
    '/home/michel/Workspace/lab/examples_posts/modules_npm/node_modules',
    '/home/michel/Workspace/lab/examples_posts/node_modules',
    '/home/michel/Workspace/lab/node_modules',
    '/home/michel/Workspace/node_modules',
    '/home/michel/node_modules',
    '/home/node_modules',
    '/node_modules'
  ]
}
Filename =>  /home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js
Dirname =>  /home/michel/Workspace/lab/examples_posts/modules_npm

Isso acontece porque quando executamos o nosso script (módulo) ele é encapsulado pela função já citada acima e seus parâmetros ficam disponíveis no contexto do atual módulo.

O parâmetro exports é uma referência para o module.exports (atalho) e contém tudo que é exportado dentro do nosso módulo, no momento como não estamos exportando nada o valor atual é: {}

Vamos fazer um teste e exporta algo no nosso módulo, uma variável “name” por exemplo, o código vai ficar assim:

exports.name = 'João';

console.log('Exports => ', exports);
console.log('Require => ', require);
console.log('Module => ', module);
console.log('Filename => ', __filename);
console.log('Dirname => ', __dirname);

E o resultado será esse:

Exports =>  { name: 'João' }
Require =>  [Function: require] {
  resolve: [Function: resolve] { paths: [Function: paths] },
  main: Module {
    id: '.',
    path: '/home/michel/Workspace/lab/examples_posts/modules_npm',
    exports: { name: 'João' },
    parent: null,
    filename: '/home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js',
    loaded: false,
    children: [],
    paths: [
      '/home/michel/Workspace/lab/examples_posts/modules_npm/node_modules',
      '/home/michel/Workspace/lab/examples_posts/node_modules',
      '/home/michel/Workspace/lab/node_modules',
      '/home/michel/Workspace/node_modules',
      '/home/michel/node_modules',
      '/home/node_modules',
      '/node_modules'
    ]
  },
  extensions: [Object: null prototype] {
    '.js': [Function],
    '.json': [Function],
    '.node': [Function]
  },
  cache: [Object: null prototype] {
    '/home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js': Module {
      id: '.',
      path: '/home/michel/Workspace/lab/examples_posts/modules_npm',
      exports: [Object],
      parent: null,
      filename: '/home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js',
      loaded: false,
      children: [],
      paths: [Array]
    }
  }
}
Module =>  Module {
  id: '.',
  path: '/home/michel/Workspace/lab/examples_posts/modules_npm',
  exports: { name: 'João' },
  parent: null,
  filename: '/home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js',
  loaded: false,
  children: [],
  paths: [
    '/home/michel/Workspace/lab/examples_posts/modules_npm/node_modules',
    '/home/michel/Workspace/lab/examples_posts/node_modules',
    '/home/michel/Workspace/lab/node_modules',
    '/home/michel/Workspace/node_modules',
    '/home/michel/node_modules',
    '/home/node_modules',
    '/node_modules'
  ]
}
Filename =>  /home/michel/Workspace/lab/examples_posts/modules_npm/myModule.js
Dirname =>  /home/michel/Workspace/lab/examples_posts/modules_npm

Agora podemos ver que a variável exports no nosso resultado contém em seu objeto a propriedade name com o valor João, isso vai se manter para tudo que exportamos no nosso módulo (função, classe e etc).

O parâmetro require armazena o resultado de module.exports seguido de algumas propriedades adicionais como cache, observe o retorno do script mencionado acima.
O parâmetro module armazena as informações do module em geral, é um objeto criado pelo Module system.
O parâmetro __filename é o nome do arquivo (com o caminho completo) e o __dirname é o diretório onde o arquivo foi encontrado (caminho completo).

Esse foi um resumo de como o export em NodeJS funciona focado na função wrapped, espero que tenha ficado entendível. È claro que essa é uma parte do processo e existe mais alguns passos quando a gente faz require de um módulo até ele ser retornado mas é um pouco “baixo nível” e não sei se teria tanta relevância entrar nos mínimos detalhe aqui, claro se você quiser pesquisar mais a fundo sentasse a vontade, vou deixar aqui uma imagem que resume todo esse processo.

Font: Node Js Cookbook

Se quiser saber mais: Modules DOC

NPM Scripts

Usar os scripts do npm ao nosso favor pode ser uma poderosa ferramenta para nos auxiliar no dia a dia automatizando pequenas tarefas. Podemos configurar scripts a ser executado na sessão “scripts” no arquivo package.json, por exemplo vamos configurar para rodar nossos testes unitários com jest, ficaria assim:

"scripts": {
    "test": "jest"
},

Se executamos “npm test” no terminal nossos testes unitários será executado.

Esse script “test” é um dos vários scripts pré definidos do npm, você pode ver a lista completa aqui Doc npm scripts.
Além desses scripts pré definidos a gente pode criar nossos próprios scripts adicionando uma propriedade no objeto da sessão “scripts” no package.json, a única diferença é que para executar nossos scripts “custom” vamos ter que add a prop run na execução do script ficando assim: “npm run ”, vamos ver os exemplos:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>"scripts": { "test": "jest", "start": "echo \"Start something\"", "say_my_name": "echo \"Michel\"" }, </code></pre></div> <p></p> <p>Ao executar o comando “npm run say_my_name” no terminal o nome “Michel” será mostrado na tela.</p> <p>Podemos fazer também encadeamento de scripts, exemplo:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>"scripts": { "test": "jest", "start": "echo \"Start something\"", "say_my_name": "echo \"Michel\"", "say_my_name:full": "npm run say_my_name \"Araujo\"" }, </code></pre></div> <p></p> <p>Acrescentamos uma linha “"say_my_name:full": "npm run say_my_name \"Araujo\""” que vai executar o script “say_my_name” e adicionar a palavra “Araujo”, se executamos esse script o resultado será o seguinte:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>npm run say_my_name:full Resultado: “Michel Araujo” </code></pre></div> <p></p> <p>Assim podemos fazer o encadeamento de script o quanto precisamos, exemplo:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>"scripts": { "say_my_name_test": "npm test && npm run say_my_name \"Araujo\"" }, </code></pre></div> <p></p> <p><strong>IMPORTANTE</strong>: O carácter “&&” fazer a divisão de chamada sincronamente, no exemplo primeiro o “npm test” será executado e depois o “npm run say_my_name”, para fazer chamadas assíncronas basta usar somente um caractere “&”, exemplo:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>"scripts": { "say_my_name_test": "npm test & npm run say_my_name \"Araujo\"" }, </code></pre></div> <p></p> <p>Vale ressaltar que os scripts no npm é um sh portanto pode ser usado com comandos shell, exemplo:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>"scripts": { "list": "ls -la" }, </code></pre></div> <p></p> <p><code>npm run list</code></p> <p>Sendo assim podemos abusar da nossa criatividade!</p> <p>Nota: Vale a pena citar que quando executamos um script npm os diretórios atual “node_modules/.bin” são adicionados a variável de ambiente PATH, sendo assim mesmo se não tivemos uma diferença de algum executável no PATH do sistema podemos referenciar no scripts do npm que irá funcionar.</p> <p>Vale uma menção honrosa aqui sobre os scripts hook dê uma olhada aqui <a href="https://docs.npmjs.com/misc/scripts">doc npm scripts</a> para saber mais.</p> <h2> <a name="como-configurar-um-registry-scope" href="#como-configurar-um-registry-scope" class="anchor"> </a> <strong>Como configurar um registry Scope</strong> </h2> <p>Vamos dizer que você tem um registry local e você quer mandar seus módulos para lá como também baixar do mesmo sem afetar o registry padrão ou seja sem influenciar nas outras dependências, você pode criar um Scope para isso simplesmente usando o caractere “@” no nome do módulo, exemplo:</p> <p><code>"name": "@local/mymoduletest",</code></p> <p>Assim quando fomos usar esse módulo como dependência<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>dependencies": { "express": "^4.17.1", "@local/mymoduletest": "^1.0.0" } </code></pre></div> <p></p> <p>E executar npm install o express será baixado do registry padrão e o @local/mymoduletest do nosso registry local.</p> <p>Exemplo de como ficou nosso package-lock:<br> </p> <div class="highlight"><pre class="highlight plaintext"><code>"@local/mymoduletest": { "version": "1.0.0", "resolved": "http://localhost:4873/@local%2fmymoduletest/-/mymoduletest-1.0.0.tgz", "integrity": "sha512-7+mejz" }, </code></pre></div> <p></p> <p>Observe a prop “resolved”.</p> <p>Usei o Sinopia para criar um registry local e executar esse exemplo.</p> <h2> <a name="boas-ferramentas" href="#boas-ferramentas" class="anchor"> </a> <strong>Boas ferramentas!</strong> </h2> <p><strong>Sinopia:</strong> Permite que você tenha um registry local e privado com facilidade, tem uma boa integração com o <a href="http://npmjs.org/">http://npmjs.org/</a> pode ser usado como cache do npm. Pode ser usado com Docker =)<br> Saiba mais em: <a href="https://www.npmjs.com/package/sinopia">https://www.npmjs.com/package/sinopia</a></p> <p><strong>IPFS protocol:</strong> Pode ser usado como uma alternativa ao registry oficial do npm para fazer publicação de módulos.<br> Saiba mais em: <a href="https://ipfs.io/">https://ipfs.io/</a> e <a href="https://www.npmjs.com/package/stay-cli">https://www.npmjs.com/package/stay-cli</a></p> <p><strong>Registry-static:</strong> Literalmente baixa todo o registry do NPM na máquina local (mais de 200 Gbs) parece absurdo mas pode ser uma boa opção de cache para o npm install ficar mais rápido.<br> Saiba mais em: <a href="https://www.npmjs.com/package/registry-static">https://www.npmjs.com/package/registry-static</a></p> <h2> <a name="referencias" href="#referencias" class="anchor"> </a> <strong>Referencias:</strong> </h2> <ul> <li>Node Cookbook - <a href="https://www.packtpub.com/web-development/node-cookbook-third-edition">https://www.packtpub.com/web-development/node-cookbook-third-edition</a></li> <li>Node.js Docs - <a href="https://nodejs.org/en/docs/">https://nodejs.org/en/docs/</a></li> <li>Npm Docs - <a href="https://docs.npmjs.com/">https://docs.npmjs.com/</a></li> </ul> <p><strong>Stay hungry Stay foolish!</strong></p>