O modelo de callbacks do JavaScript era o único mecanismo para E/S não bloqueante quando o Node.js surgiu em 2009. Quando as Promises foram introduzidas no ES6 e o async/await no ES2017, a maioria dos códigos de produção já contava com anos de lógica baseada em callbacks em funcionamento: manipuladores de erros aninhados, estado mutável compartilhado e encadeado por closures, lógica de repetição embutida em funções anônimas com até três níveis de profundidade. A sintaxe mudou. O código em execução, não. Hoje, a maioria das equipes de engenharia herda exatamente essa situação: um código onde os padrões novos e os antigos coexistem, onde a equipe quer migrar, mas o sistema não pode parar enquanto isso acontece.
Migre seu código assíncrono com segurança.
SMART TS XL e identifica riscos de migração em toda a sua base de código antes mesmo de você alterar uma única linha.
Explore agoraA boa notícia é que a migração não exige uma reescrita. Callbacks, Promises e async/await são interoperáveis em limites bem definidos. O Node.js já vem com tudo isso integrado. util.promisify Precisamente para preencher a lacuna entre callbacks que priorizam erros e funções que retornam Promises. Camadas de encapsulamento permitem que o código antigo e o novo coexistam durante a transição. A migração incremental, um módulo por vez, mantém a produção em funcionamento enquanto a base de código evolui. O desafio não é a transformação em si, mas fazê-la sistematicamente: entender quais callbacks podem ser convertidos primeiro com segurança, quais antipadrões causarão bugs se forem reescritos de forma ingênua e como validar se cada função convertida se comporta de forma idêntica à que substituiu.
Entendendo o modelo de callback e por que ele falha em grande escala.
A convenção de callbacks do Node.js é simples: funções que realizam trabalho assíncrono aceitam um callback como último argumento. O callback recebe um erro como primeiro argumento e o resultado como segundo. Todas as funções da biblioteca padrão do Node.js seguem essa convenção: fs.readFile, http.get, child_process.exece centenas mais.
javascript
// Standard Node.js error-first callback pattern
const fs = require('fs');
fs.readFile('config.json', 'utf8', (err, data) => {
if (err) {
console.error('Failed to read config:', err);
return;
}
const config = JSON.parse(data);
console.log('Config loaded:', config);
});Esse padrão é simples para uma única operação. Ele falha quando as operações precisam ser encadeadas, pois cada operação subsequente deve ser iniciada dentro do callback anterior. Uma sequência de três etapas — leitura, transformação e escrita — produz três níveis aninhados de callbacks. Uma sequência de cinco etapas produz cinco. Essa é a estrutura que os desenvolvedores chamam de "inferno de callbacks" ou "pirâmide da perdição", e não se trata apenas de um problema estético. Callbacks profundamente aninhados tornam o tratamento de erros inconsistente (cada nível deve verificar seu argumento de erro independentemente), dificultam o raciocínio sobre a ordem de execução e tornam a refatoração perigosa, pois o fluxo de dados se torna implícito em vez de explícito.
O problema mais crítico para sistemas de produção é que os callbacks não possuem um mecanismo nativo para coordenação. Executar duas operações assíncronas e aguardar a conclusão de ambas requer o controle manual de contadores. Executar uma sequência de operações em um array requer padrões recursivos ou bibliotecas de terceiros, como... asyncNada dessa complexidade é visível nas assinaturas das funções: uma API baseada em callbacks e uma orquestração concorrente construída sobre ela parecem idênticas externamente, até que falhem.
Como é, de fato, o inferno dos callbacks
Uma pirâmide de callbacks do mundo real, proveniente de um serviço Node.js, que lê dados do usuário, valida permissões e registra o acesso:
javascript
// Three-level callback pyramid -- representative of real legacy code
function getUserReport(userId, callback) {
db.query('SELECT * FROM users WHERE id = ?', [userId], (err, user) => {
if (err) return callback(err);
if (!user) return callback(new Error('User not found'));
permissions.check(userId, 'read:reports', (err, allowed) => {
if (err) return callback(err);
if (!allowed) return callback(new Error('Permission denied'));
auditLog.write({ userId, action: 'read:reports' }, (err) => {
if (err) return callback(err);
// Finally, the actual work
callback(null, buildReport(user));
});
});
});
}O tratamento de erros se repete em todos os níveis. A indentação torna o fluxo de dados visualmente complexo. Adicionar uma quarta etapa requer outro nível aninhado. Testar essa função exige simular todas as três dependências em ordem, e simular um erro no terceiro nível exige que as duas primeiras sejam simuladas com sucesso. Cada uma dessas características piora à medida que a cadeia cresce.
Utilizando util.promisify para fazer a ponte entre callbacks e promessas.
O Node.js 8.0 introduziu... util.promisify, que converte qualquer função que siga a convenção padrão de retorno de chamada com erro em uma função que retorna uma Promise. Este é o ponto de partida correto para qualquer migração para async/await em um código Node.js.
javascript
const { promisify } = require('util');
const fs = require('fs');
// Convert Node.js built-ins
const readFile = promisify(fs.readFile);
const writeFile = promisify(fs.writeFile);
// Now usable with async/await
async function processConfig(path) {
const data = await readFile(path, 'utf8');
const config = JSON.parse(data);
config.lastLoaded = Date.now();
await writeFile(path, JSON.stringify(config, null, 2), 'utf8');
return config;
}util.promisify Lida automaticamente com a convenção de erro primeiro: se o retorno de chamada receber um primeiro argumento não nulo, a Promise retornada será rejeitada com esse erro. Se o retorno de chamada receber um primeiro argumento nulo e um resultado, a Promise será resolvida com o resultado. Para a grande maioria das APIs principais do Node.js e bibliotecas de terceiros que seguem essa convenção, nenhum encapsulamento personalizado é necessário.
Funções de retorno de chamada personalizadas promissoras
Para funções personalizadas que seguem a convenção de erro primeiro, mas não são funções nativas do Node.js, util.promisify funciona de forma idêntica:
javascript
const { promisify } = require('util');
// Your existing callback-based function
function fetchUserFromDB(userId, callback) {
db.query('SELECT * FROM users WHERE id = ?', [userId], (err, rows) => {
if (err) return callback(err);
callback(null, rows[0] || null);
});
}
// Promisified version -- no changes to the original function needed
const fetchUser = promisify(fetchUserFromDB);
// Use in async context
async function getUser(userId) {
const user = await fetchUser(userId);
if (!user) throw new Error(`User ${userId} not found`);
return user;
}Essa abordagem é importante: util.promisify A função original é encapsulada sem ser modificada. A versão original com callback continua funcionando. Quem chama a função e ainda não foi migrado continua usando a versão com callback. Quem já foi migrado usa a versão com promisificação. Essa coexistência é o que torna a migração incremental possível.
Tratamento de assinaturas de retorno de chamada não padronizadas
Algumas bibliotecas mais antigas passam múltiplos valores de resultado para seus callbacks, o que util.promisify resolve-se apenas no primeiro valor. Nesses casos, o util.promisify.custom O símbolo permite definir uma promisificação personalizada:
javascript
const { promisify } = require('util');
// A function that passes two results to its callback
function parseData(input, callback) {
// callback(err, parsedData, metadata)
callback(null, { value: input.trim() }, { length: input.length });
}
// Custom promisification that returns both results
parseData[promisify.custom] = (input) => {
return new Promise((resolve, reject) => {
parseData(input, (err, data, meta) => {
if (err) reject(err);
else resolve({ data, meta });
});
});
};
const parseDataAsync = promisify(parseData);
const result = await parseDataAsync(' hello ');
// result === { data: { value: 'hello' }, meta: { length: 9 } }Convertendo Callbacks em Promises: O Padrão Passo a Passo
Para código que não pode ser tratado por util.promisify Diretamente, o wrapper Promise manual é o caminho de migração. O padrão é consistente:
javascript
// Step 1: Original callback-based function
function checkPermission(userId, resource, callback) {
acl.check({ userId, resource }, (err, result) => {
if (err) return callback(err);
callback(null, result.allowed);
});
}
// Step 2: Promise wrapper (coexists with the original)
function checkPermissionAsync(userId, resource) {
return new Promise((resolve, reject) => {
checkPermission(userId, resource, (err, allowed) => {
if (err) reject(err);
else resolve(allowed);
});
});
}
// Step 3: async/await consumer
async function authorizeRequest(userId, resource) {
const allowed = await checkPermissionAsync(userId, resource);
if (!allowed) {
throw new Error(`${userId} does not have access to ${resource}`);
}
}A pirâmide de callbacks de três níveis mencionada anteriormente, reescrita com async/await:
javascript
// After migration: same logic, linear structure
async function getUserReport(userId) {
const user = await db.queryAsync('SELECT * FROM users WHERE id = ?', [userId]);
if (!user) throw new Error('User not found');
const allowed = await permissions.checkAsync(userId, 'read:reports');
if (!allowed) throw new Error('Permission denied');
await auditLog.writeAsync({ userId, action: 'read:reports' });
return buildReport(user);
}O tratamento de erros agora é feito por um único bloco try/catch no ponto de chamada, em vez de ser repetido em todos os níveis. O recuo é plano. Adicionar uma quarta etapa requer mais uma etapa. await linha. Os testes exigem a simulação de cada dependência de forma independente, em qualquer ordem.
Execução paralela com Promise.all e Promise.allSettled
Um dos erros mais comuns na migração de callbacks para async/await é a execução sequencial de operações que poderiam ser executadas em paralelo. Os callbacks tornavam a execução paralela tão complexa que muitos desenvolvedores optavam por cadeias sequenciais. O async/await faz com que o paralelismo pareça sequencial, o que pode levar os desenvolvedores a escreverem código mais lento do que sua versão anterior com callbacks.
javascript
// WRONG: sequential execution -- each awaits the previous result
async function loadDashboardData(userId) {
const profile = await fetchProfile(userId); // 100ms
const orders = await fetchOrders(userId); // 150ms
const reviews = await fetchReviews(userId); // 80ms
return { profile, orders, reviews }; // Total: ~330ms
}
// RIGHT: parallel execution with Promise.all
async function loadDashboardData(userId) {
const [profile, orders, reviews] = await Promise.all([
fetchProfile(userId),
fetchOrders(userId),
fetchReviews(userId),
]);
return { profile, orders, reviews }; // Total: ~150ms
}Promise.all Rejeita se alguma Promise no array for rejeitada. Quando operações independentes podem falhar sem se afetar mutuamente e o chamador precisa saber sobre todas as falhas, Promise.allSettled é a ferramenta correta:
javascript
// Promise.allSettled: runs all, reports success or failure per operation
async function syncAllSources(userId) {
const results = await Promise.allSettled([
syncFromGitHub(userId),
syncFromJira(userId),
syncFromSlack(userId),
]);
const failed = results
.filter(r => r.status === 'rejected')
.map(r => r.reason.message);
if (failed.length > 0) {
console.warn('Some syncs failed:', failed);
}
return results
.filter(r => r.status === 'fulfilled')
.map(r => r.value);
}Esse padrão não tem equivalente natural em código baseado em callbacks sem um contador manual ou uma biblioteca como async.parallelMigrando para Promise.allSettled Geralmente é uma das mudanças de maior impacto em uma base de código assíncrona legada.
Evitando o antipadrão de espera em loop
O erro de usar sequência em vez de paralelo ocorre com mais frequência dentro de loops:
javascript
// WRONG: sequential -- processes items one at a time
async function processOrders(orderIds) {
const results = [];
for (const id of orderIds) {
const result = await processOrder(id); // blocks until each completes
results.push(result);
}
return results;
}
// RIGHT: parallel -- all orders processed concurrently
async function processOrders(orderIds) {
return Promise.all(orderIds.map(id => processOrder(id)));
}
// RIGHT (with concurrency limit): parallel but bounded
const pLimit = require('p-limit');
const limit = pLimit(5); // max 5 concurrent
async function processOrders(orderIds) {
return Promise.all(
orderIds.map(id => limit(() => processOrder(id)))
);
}O padrão await-in-loop é uma das regressões mais comuns introduzidas durante a migração de código baseado em callbacks para async/await, porque os callbacks forçavam os desenvolvedores a pensar explicitamente sobre concorrência, enquanto o async/await a obscurece.
Tratamento de erros em Async/Await: Substituindo a propagação de erros de retorno de chamada
Por convenção, as funções de retorno de chamada (callbacks) propagam erros: o primeiro argumento de cada callback é um erro ou nulo. Isso funciona, mas exige que cada chamador verifique manualmente o argumento de erro. O protocolo async/await propaga erros por meio do mecanismo de rejeição de Promises, que se integra ao bloco try/catch nativo do JavaScript.
javascript
// Callback error propagation: repeated at every level
function processPayment(orderId, callback) {
validateOrder(orderId, (err, order) => {
if (err) return callback(err); // propagate
chargeCard(order.amount, (err, charge) => {
if (err) return callback(err); // propagate again
updateInventory(orderId, (err) => {
if (err) return callback(err); // propagate again
callback(null, charge.id);
});
});
});
}
// Async/await: error propagation is automatic
async function processPayment(orderId) {
const order = await validateOrder(orderId); // throws on error
const charge = await chargeCard(order.amount); // throws on error
await updateInventory(orderId); // throws on error
return charge.id;
}Uma consideração crucial durante a migração é a preservação do contexto de erro. O código baseado em callbacks frequentemente repassa erros que foram enriquecidos com informações contextuais em cada nível. Ao migrar para async/await, assegure-se de que o tratamento de erros preserve esse contexto.
javascript
// Preserving error context during async migration
async function processPayment(orderId) {
let order;
try {
order = await validateOrder(orderId);
} catch (err) {
throw new Error(`Payment validation failed for order ${orderId}: ${err.message}`);
}
try {
const charge = await chargeCard(order.amount);
await updateInventory(orderId);
return charge.id;
} catch (err) {
// Attempt rollback, then rethrow with context
await refundCharge(order.amount).catch(console.error);
throw new Error(`Payment processing failed for order ${orderId}: ${err.message}`);
}
}Rejeições de promessas não resolvidas
O código baseado em callbacks ignora silenciosamente os erros quando o argumento de erro é descartado. Async/await gera rejeições de Promises não tratadas, que no Node.js 15+ causam o encerramento do processo por padrão. Essa é uma mudança que quebra a compatibilidade ao migrar: o código que antes falhava silenciosamente agora causará um erro.
javascript
// This produces an unhandled rejection in Node.js 15+
async function riskyOperation() {
throw new Error('Something failed');
}
riskyOperation(); // Promise rejected, but rejection is not caught
// Fix: always await or chain .catch()
await riskyOperation(); // throws, caller handles it
riskyOperation().catch(console.error); // handles inlineAudite todas as chamadas de funções assíncronas do tipo "disparar e esquecer" durante a migração. Qualquer chamada para uma função assíncrona cujo valor de retorno não seja aguardado ou encadeado com .catch() É uma possível falha silenciosa no mundo dos callbacks, mas uma falha de rejeição não tratada no mundo do async/await.
Migrando padrões EventEmitter para Promises e iteradores assíncronos
Os EventEmitters do Node.js são um tipo de padrão de callback onde múltiplos callbacks são registrados para eventos nomeados. Eles são comuns em fluxos de dados, conexões de rede e barramentos de eventos personalizados. A migração direta para async/await requer o encapsulamento da API baseada em eventos.
javascript
const { EventEmitter } = require('events');
// Original EventEmitter-based pattern
function fetchDataLegacy(source) {
const emitter = new EventEmitter();
setTimeout(() => {
emitter.emit('data', { records: [1, 2, 3] });
emitter.emit('end');
}, 100);
return emitter;
}
// Usage: callback registration
const stream = fetchDataLegacy('api');
stream.on('data', chunk => console.log('received', chunk));
stream.on('error', err => console.error('error', err));
stream.on('end', () => console.log('done'));Converter um evento único em uma Promise é simples:
javascript
// Converting a single-event completion to Promise
function waitForEvent(emitter, successEvent, errorEvent = 'error') {
return new Promise((resolve, reject) => {
emitter.once(successEvent, resolve);
emitter.once(errorEvent, reject);
});
}
async function fetchData(source) {
const emitter = fetchDataLegacy(source);
const data = await waitForEvent(emitter, 'data');
await waitForEvent(emitter, 'end');
return data;
}Para fluxos que emitem múltiplos eventos de dados, o Node.js fornece events.on que retorna um iterador assíncrono, permitindo que o fluxo completo seja consumido com for await...of:
javascript
const { on } = require('events');
async function processStream(readable) {
for await (const chunk of on(readable, 'data')) {
await processChunk(chunk);
}
}Os fluxos legíveis do Node.js também são diretamente iteráveis como iteráveis assíncronos desde o Node 10:
javascript
const fs = require('fs');
async function countLines(filePath) {
let lines = 0;
const stream = fs.createReadStream(filePath, { encoding: 'utf8' });
for await (const chunk of stream) {
lines += chunk.split('\n').length - 1;
}
return lines;
}Padrões de migração Async/Await do TypeScript
Ao migrar para async/await, é preciso considerar aspectos adicionais do código TypeScript. Os tipos de retorno devem ser atualizados, passando de assinaturas de callback para Promise<T>E o compilador garante que o await seja usado apenas dentro de funções assíncronas.
datilografado
// Before: callback signature
function fetchUser(
id: string,
callback: (err: Error | null, user: User | null) => void
): void {
db.findOne({ id }, callback);
}
// After: async/await signature with proper return type
async function fetchUser(id: string): Promise<User> {
const user = await db.findOneAsync<User>({ id });
if (!user) throw new Error(`User ${id} not found`);
return user;
}As verificações rigorosas de nulo do TypeScript interagem com o código assíncrono de uma forma que detecta erros comuns de migração. Se uma função anteriormente retornava nulo, ela será detectada. User | null por meio de um retorno de chamada e a migração o altera para Promise<User> (Lançando uma exceção em vez de retornar nulo), o TypeScript detectará chamadas que verificavam se havia nulo, mas não precisam mais fazê-lo, e chamadas que não verificavam erros que agora precisam ser tratados.
Para código TypeScript legado que usa o @types/node assinaturas de retorno de chamada, util.promisify É totalmente tipado e infere automaticamente o tipo de retorno Promise correto para funções internas do Node.js.
Estratégia de Migração Incremental para Sistemas de Produção
Um sistema de produção não pode ser migrado de uma só vez. A abordagem incremental converte um módulo por vez, valida-o e, em seguida, passa para o próximo. A chave é manter uma separação clara entre o código convertido e o não convertido em cada etapa.
A ordem de migração deve seguir a direção das dependências: converta primeiro as dependências mais profundas e, em seguida, trabalhe para cima, em direção às funções que as chamam. Isso garante que, quando uma função de nível superior for convertida, suas dependências já estejam retornando Promises e a camada de encapsulamento não seja mais necessária.
javascript
// Stage 1: Promisify the data layer (deepest dependency)
const db = {
queryAsync: promisify(db.query.bind(db)),
insertAsync: promisify(db.insert.bind(db)),
};
// Stage 2: Convert the service layer (depends on db)
class UserService {
async getUser(id) {
return db.queryAsync('SELECT * FROM users WHERE id = ?', [id]);
}
async createUser(data) {
return db.insertAsync('users', data);
}
}
// Stage 3: Convert the controller layer (depends on service)
// -- only after Stage 2 is validated and deployed
async function handleGetUser(req, res) {
try {
const user = await userService.getUser(req.params.id);
res.json(user);
} catch (err) {
res.status(500).json({ error: err.message });
}
}Essa abordagem em etapas é diretamente suportada por ferramentas de análise. Conforme discutido na análise de fluxo de dados e controle , entender como os dados fluem pelas camadas assíncronas antes de modificá-las é o pré-requisito para uma refatoração incremental segura. A direção da dependência determina quais módulos podem ser convertidos primeiro e quais devem esperar até que suas dependências já tenham sido migradas.
Camadas de encapsulamento para compatibilidade com versões anteriores
Durante a migração, alguns usuários ainda esperarão APIs baseadas em callbacks. util.callbackify a função é o inverso de util.promisify: converte uma função assíncrona de volta para uma interface de retorno de chamada que prioriza erros:
javascript
const { callbackify } = require('util');
// New async implementation
async function fetchUserAsync(id) {
return db.queryAsync('SELECT * FROM users WHERE id = ?', [id]);
}
// Backward-compatible callback version for unconverted callers
const fetchUser = callbackify(fetchUserAsync);
// Old callers continue to work unchanged
fetchUser(userId, (err, user) => {
if (err) return handleError(err);
render(user);
});
// New callers use the async version directly
const user = await fetchUserAsync(userId);Essa compatibilidade bidirecional significa que a conversão não é um evento pontual. Módulos individuais podem ser convertidos em qualquer sprint sem a necessidade de coordenação simultânea com todos os responsáveis pela chamada.
Armadilhas comuns do Async/Await durante a migração
Falta de await em chamadas de funções assíncronas
O erro de migração mais comum é chamar uma função assíncrona sem usar `await`. Isso é invisível para o ambiente de execução do JavaScript, a menos que a função seja rejeitada, e a rejeição se torna uma rejeição de Promise não tratada em vez de um erro lançado.
javascript
// Bug: missing await -- function runs but result is a Promise, not the user
async function updateUserName(id, name) {
const user = fetchUser(id); // BUG: forgot await, user is a Promise object
user.name = name; // setting .name on a Promise, not a user
await saveUser(user); // saves the Promise object
}
// Fix
async function updateUserName(id, name) {
const user = await fetchUser(id);
user.name = name;
await saveUser(user);
}TypeScript e ESLint no-floating-promises A regra detecta esse padrão automaticamente. É altamente recomendável adicionar essa regra de verificação durante a migração.
Funções assíncronas em métodos de matriz
Array.prototype.forEach Não aguarda callbacks assíncronos. Isso produz o mesmo comportamento sequencial, porém incorreto, que o `await-in-loop`, exceto que o código parece funcionar enquanto executa silenciosamente todos os callbacks simultaneamente, sem aguardar nenhum:
javascript
// Bug: forEach does not await async callbacks
async function processAll(ids) {
ids.forEach(async (id) => {
await processItem(id); // these run concurrently, forEach completes immediately
});
// function returns before any processItem completes
}
// Fix: use Promise.all with map
async function processAll(ids) {
await Promise.all(ids.map(id => processItem(id)));
}O bloco try/catch não captura erros assíncronos fora do await.
Um bloco try/catch captura apenas erros de expressões aguardadas (await). Uma chamada de função assíncrona sem await não terá sua rejeição capturada por um bloco try/catch externo.
javascript
// Bug: the rejection from riskyOp() is not caught
async function run() {
try {
riskyOp(); // not awaited -- rejection escapes the try/catch
} catch (err) {
console.error(err); // never reached
}
}
// Fix: await inside the try block
async function run() {
try {
await riskyOp();
} catch (err) {
console.error(err);
}
}Testando código assíncrono após a migração
Funções assíncronas migradas exigem casos de teste assíncronos. Os frameworks de teste modernos oferecem suporte nativo a isso.
javascript
// Jest async test patterns
describe('UserService', () => {
// Pattern 1: async/await in test
test('fetches user by id', async () => {
const user = await userService.getUser('user-123');
expect(user.id).toBe('user-123');
});
// Pattern 2: testing rejection
test('throws when user not found', async () => {
await expect(userService.getUser('nonexistent'))
.rejects.toThrow('User nonexistent not found');
});
// Pattern 3: parallel setup
beforeAll(async () => {
await db.connect();
await db.seed(testData);
});
afterAll(async () => {
await db.cleanup();
await db.disconnect();
});
});Ao validar se uma função migrada produz resultados idênticos à sua predecessora de retorno de chamada, o teste de comparação é eficaz:
javascript
// Comparison test: callback version vs. async version must agree
test('async version matches callback version output', async () => {
const callbackResult = await promisify(fetchUserLegacy)('user-123');
const asyncResult = await fetchUserAsync('user-123');
expect(asyncResult).toEqual(callbackResult);
});Esse padrão de teste é particularmente útil durante o período de transição, quando ambas as versões estão sendo executadas em paralelo. Conforme analisado no contexto da análise de impacto antes de alterações no código , validar se uma função refatorada produz resultados idênticos aos da sua predecessora é a confirmação baseada em evidências de que a migração está correta antes da remoção da versão antiga.
Como SMART TS XL Suporta migração assíncrona segura em escala.
Para bases de código corporativas onde as cadeias de retorno de chamada abrangem vários arquivos, serviços e equipes, o primeiro requisito para uma migração segura é um mapeamento completo das dependências assíncronas existentes: quais funções chamam quais, quais dados são transmitidos entre elas, quais cadeias são caminhos críticos para as operações principais do aplicativo e quais são utilitários isolados que podem ser migrados independentemente.
SMART TS XL O sistema constrói esse mapa de dependências analisando todo o código-fonte, e não apenas arquivos individuais. Ele resolve como as funções baseadas em callbacks se referenciam entre si em diferentes módulos, identifica qual estado compartilhado é transmitido por meio de closures e visualiza as cadeias de execução que devem permanecer intactas durante a migração. Essa análise estrutural fornece a base para a abordagem de migração em etapas descrita neste guia: quais módulos estão na base do grafo de dependências e podem ser convertidos primeiro, e quais módulos devem esperar até que suas dependências já tenham sido migradas.
A plataforma análise de impacto A capacidade amplia isso para a avaliação de mudanças. Antes de converter um módulo baseado em callbacks para retornar Promises, a análise de impacto identifica todos os outros módulos no código-fonte que o chamam com uma interface de callback. Esses módulos que o chamam são o escopo de migração para a próxima etapa: eles devem ser convertidos simultaneamente ou um wrapper retrocompatível usando util.callbackify devem ser mantidas até que sejam convertidas. Sem essa enumeração, as migrações prosseguem com escopo desconhecido e produzem quebras inesperadas quando os chamadores não identificados encontram uma Promise onde esperavam um retorno de chamada.
Para bases de código que misturam JavaScript com TypeScript, ou que fazem chamadas para serviços de backend em outras linguagens, SMART TS XL'S análise de dependência entre idiomas Oferece visibilidade de todo o caminho de execução, não apenas da camada JavaScript. Uma cadeia de callbacks que termina em uma chamada a um serviço externo escrito em Java ou Python tem dependências que ferramentas de linguagem única não conseguem enxergar, e o planejamento de migração que ignora essas dependências fica incompleto. visualização de dependências que. SMART TS XL Isso torna visíveis essas relações transfronteiriças antes que quaisquer alterações migratórias sejam feitas.
Sustentando a Migração: De Callbacks para Async/Await em Toda a Base de Código
A transição de callbacks para async/await não se completa quando o primeiro módulo é convertido. Ela se completa quando a última camada de encapsulamento é removida e não há mais nenhum código-fonte restante. callback A convenção está presente em sua lógica central. Para chegar lá, é necessário disciplina durante todo o período de migração: o novo código deve ser escrito em async/await, as camadas de encapsulamento devem ser tratadas como temporárias e as regras do ESLint devem garantir que funções no estilo callback não sejam introduzidas nos módulos convertidos.
Os indicadores práticos de uma migração concluída são: não. util.promisify chamadas no código do aplicativo (elas foram necessárias apenas durante o período de transição), não (err, result) => padrões na lógica de negócios principal (eles foram substituídos por try/catch em funções assíncronas), sem construtores de Promise manuais onde async/await bastaria, e Promise.all em todos os locais onde anteriormente eram executadas operações independentes em sequência.
Cada um desses aspectos é mensurável por meio de análise estática, o que significa que o progresso pode ser acompanhado e relatado objetivamente, em vez de estimado. Para equipes que operam em grande escala, a combinação de análise estática automatizada para encontrar padrões de retorno de chamada e análise de dependência para definir o escopo de cada etapa da migração é o que faz a diferença entre uma migração concluída dentro de um prazo definido e uma que persiste indefinidamente porque o escopo nunca foi totalmente conhecido.
