ts node
1.0.0
Execução do TypeScript e Repl for Node.js, com mapa de origem e suporte de ESM nativo.
A documentação mais recente também pode ser encontrada em nosso site: https://typestrong.org/ts-node
nodeTSErrorSyntaxErrorERR_REQUIRE_ESMERR_UNKNOWN_FILE_EXTENSIONnode_modulesTS-Node é um mecanismo de execução datilografado e repl for node.js.
Ele transforma o TypeScript em JavaScript, permitindo que você execute diretamente o TypeScript no Node.js sem pré -compilar. Isso é realizado por conectar as APIs de carregamento do módulo do Node, permitindo que ele seja usado perfeitamente ao lado de outras ferramentas e bibliotecas do Node.js.
tsconfig.json
# Locally in your project.
npm install -D typescript
npm install -D ts-node
# Or globally with TypeScript.
npm install -g typescript
npm install -g ts-node
# Depending on configuration, you may also need these
npm install -D tslib @types/node Dica: a instalação de módulos localmente permite controlar e compartilhar as versões através package.json . O nó TS sempre resolverá o compilador da cwd antes de verificar em relação à sua própria instalação.
# Execute a script as `node` + `tsc`.
ts-node script.ts
# Starts a TypeScript REPL.
ts-node
# Execute code with TypeScript.
ts-node -e ' console.log("Hello, world!") '
# Execute, and print, code with TypeScript.
ts-node -p -e ' "Hello, world!" '
# Pipe scripts to execute with TypeScript.
echo ' console.log("Hello, world!") ' | ts-node
# Equivalent to ts-node --transpileOnly
ts-node-transpile-only script.ts
# Equivalent to ts-node --cwdMode
ts-node-cwd script.ts
# Equivalent to ts-node --esm
ts-node-esm script.ts Para escrever scripts com portabilidade máxima, especifique as opções em seu tsconfig.json e omite -as do shebang.
#!/usr/bin/env ts-node
// ts-node options are read from tsconfig.json
console . log ( "Hello, world!" ) A inclusão de opções dentro da shebang exige o sinalizador env -S , disponível nas versões recentes do env . (compatibilidade)
#!/usr/bin/env -S ts-node --files
// This shebang works on Mac and Linux with newer versions of env
// Technically, Mac allows omitting `-S`, but Linux requires it Para testar sua versão do env para compatibilidade com -S :
# Note that these unusual quotes are necessary
/usr/bin/env --debug ' -S echo foo bar ' Você pode registrar o nó TS sem usar nossa CLI: node -r ts-node/register node --loader ts-node/esm
Em muitos casos, a definição NODE_OPTIONS permitirá ts-node em outras ferramentas de nós, processos filhos e threads de trabalhadores. Isso pode ser combinado com outros sinalizadores de nós.
NODE_OPTIONS= " -r ts-node/register --no-warnings " node ./index.tsOu, se você precisar de suporte nativo de ESM:
NODE_OPTIONS= " --loader ts-node/esm " Isso informa a todos os processos de nó que recebem essa variável de ambiente para instalar os ganchos do ts-node antes de executar outro código.
Se você estiver invocando o nó diretamente, pode evitar a variável de ambiente e passar esses sinalizadores para o nó.
node --loader ts-node/esm --inspect ./index.ts Você pode exigir um nó TS e registrar o carregador para o futuro requer, usando require('ts-node').register({ /* options */ }) .
Confira nossa API para obter mais recursos.
O nó TS suporta uma variedade de opções que podem ser especificadas via tsconfig.json , como sinalizadores da CLI, como variáveis de ambiente ou programaticamente.
Para uma lista completa, consulte as opções.
Os sinalizadores de CLI do TS-Node devem vir antes do script de ponto de entrada. Por exemplo:
$ ts-node --project tsconfig-dev.json say-hello.ts Ronald
Hello, Ronald ! O nó TS encontra e carrega automaticamente tsconfig.json . A maioria das opções de nó TS pode ser especificada em um objeto "ts-node" usando seus nomes programáticos de camelcase. Recomendamos isso porque funciona mesmo quando você não pode passar sinalizadores da CLI, como node --require ts-node/register e, ao usar Shebangs.
Use --skipProject para pular carregando o tsconfig.json . Use --project para especificar explicitamente o caminho para um tsconfig.json .
Ao pesquisar, ele é resolvido usando o mesmo comportamento de pesquisa que tsc . Por padrão, essa pesquisa é executada em relação ao script de entrada de entrada. In --cwdMode ou se nenhum ponto de entrada for especificado -por exemplo, ao usar o REPL -a pesquisa é executada em relação a --cwd / process.cwd() .
Você pode usar esta configuração de amostra como ponto de partida:
{
// This is an alias to @tsconfig/node16: https://github.com/tsconfig/bases
"extends" : "ts-node/node16/tsconfig.json" ,
// Most ts-node options can be specified here using their programmatic names.
"ts-node" : {
// It is faster to skip typechecking.
// Remove if you want ts-node to do typechecking.
"transpileOnly" : true ,
"files" : true ,
"compilerOptions" : {
// compilerOptions specified here will override those declared below,
// but *only* in ts-node. Useful if you want ts-node and tsc to use
// different options with a single tsconfig.json.
}
} ,
"compilerOptions" : {
// typescript options here
}
}Nosso esquema JSON incluído lista todas as opções compatíveis.
@tsconfig/bases mantém configurações recomendadas para várias versões de nós. Como conveniência, eles são incluídos com o TS Node.
{
"extends" : "ts-node/node16/tsconfig.json" ,
// Or install directly with `npm i -D @tsconfig/node16`
"extends" : "@tsconfig/node16/tsconfig.json" ,
} Se nenhum tsconfig.json for carregado do disco, o TS-Node usará os padrões mais recentes recomendados de @tsconfig/bases compatíveis com as versões do node e typescript . Com o último node e typescript , este é @tsconfig/node16 .
As versões mais antigas do typescript são incompatíveis com @tsconfig/node16 . Nesses casos, usaremos uma configuração padrão mais antiga.
Em caso de dúvida, ts-node --showConfig registrará a configuração usada, e ts-node -vv registrará as versões node e typescript .
node Os sinalizadores node devem ser passados diretamente para node ; Eles não podem ser passados para o binário do TS Nó nem podem ser especificados em tsconfig.json
Recomendamos o uso da variável de ambiente NODE_OPTIONS para passar as opções para node .
NODE_OPTIONS= ' --trace-deprecation --abort-on-uncaught-exception ' ts-node ./index.ts Como alternativa, você pode invocar node diretamente e instalar o nó TS via --require / -r
node --trace-deprecation --abort-on-uncaught-exception -r ts-node/register ./index.ts Todos os sinalizadores da linha de comando suportam --camelCase e --hyphen-case .
A maioria das opções pode ser declarada em seu tsconfig.json: configuração via tsconfig.json
ts-node suporta --print ( -p ), --eval ( -e ), --require ( -r ) e --interactive ( -i ) semelhante ao node.js cli.
ts-node suporta --project e --showConfig semelhante à CLI da TSC.
Variáveis de ambiente, quando disponíveis, estão em ALL_CAPS
ts-node --helpImprime o texto de ajuda
ts-node -v
ts-node -vvv Imprime a versão. -vv inclui versões do compilador de nó e tipscript. -vvv inclui caminhos absolutos para as instalações de nó TS e TypeScript.
ts-node -e < typescript code >
# Example
ts-node -e ' console.log("Hello world!") 'Avalie o código
ts-node -p -e < typescript code >
# Example
ts-node -p -e ' "Hello world!" ' Resultado de impressão de --eval
ts-node -iAbre o REPL, mesmo que o stdin não pareça ser um terminal
ts-node --esm
ts-node-esmBootstrap com o carregador ESM, permitindo o suporte completo do ESM
ts-node -P < path/to/tsconfig >
ts-node --project < path/to/tsconfig >Caminho para o arquivo tsconfig.
Observe a maçaneta -P . Isso é diferente da opção de projeto tsc 'S -p/--project .
Ambiente: TS_NODE_PROJECT
ts-node --skipProjectSkip Project Config Resolution and Loading
Padrão: false
Ambiente: TS_NODE_SKIP_PROJECT
ts-node -c
ts-node --cwdMode
ts-node-cwdResolva Config em relação ao diretório atual em vez do diretório do script de entrada
ts-node -O < json compilerOptions >
ts-node --compilerOptions < json compilerOptions >JSON objeta -se para se fundir com opções de compilador
Ambiente: TS_NODE_COMPILER_OPTIONS
ts-node --showConfig Imprima resolvido tsconfig.json , incluindo opções ts-node e saída
ts-node -T
ts-node --transpileOnly Use transpileModule mais rápido do TypeScript
Padrão: false
Ambiente: TS_NODE_TRANSPILE_ONLY
ts-node --typeCheck Oposto de --transpileOnly
Padrão: true
Ambiente: TS_NODE_TYPE_CHECK
ts-node -H
ts-node --compilerHostUse a API do host do compilador do TypeScript
Padrão: false
Ambiente: TS_NODE_COMPILER_HOST
ts-node --files Carregue files , include e exclude do tsconfig.json na inicialização. Isso pode evitar certas falhas de escala de digitação. Veja os tipos ausentes para obter detalhes.
Padrão: false
Ambiente: TS_NODE_FILES
ts-node -D < code,code >
ts-node --ignoreDiagnostics < code,code >Ignore os avisos de texto datilografado por código de diagnóstico
Ambiente: TS_NODE_IGNORE_DIAGNOSTICS
ts-node -I < regexp matching ignored files >
ts-node --ignore < regexp matching ignored files >Substituir os padrões de caminho para pular a compilação
Padrão: /node_modules/
Ambiente: TS_NODE_IGNORE
ts-node --skipIgnoreSkip ignora cheques
Padrão: false
Ambiente: TS_NODE_SKIP_IGNORE
ts-node -C < name >
ts-node --compiler < name >Especifique um compilador de texto personalizado
Padrão: typescript
Ambiente: TS_NODE_COMPILER
ts-node --swc Transpilar com SWC. Implica --transpileOnly
Padrão: false
ts-node --transpiler < name >
# Example
ts-node --transpiler ts-node/transpilers/swcUse um transpiler de terceiros e não-toques
ts-node --preferTsExtsReordene as extensões de arquivo para que as importações de texto digital sejam preferidas
Padrão: false
Ambiente: TS_NODE_PREFER_TS_EXTS
ts-node --logErrorLogs TypeScript erros para stderr em vez de jogar exceções
Padrão: false
Ambiente: TS_NODE_LOG_ERROR
ts-node --prettyUse um formatador bonito de diagnóstico
Padrão: false
Ambiente: TS_NODE_PRETTY
TS_NODE_DEBUG=true ts-nodeAtivar log de depuração
ts-node -r < module name or path >
ts-node --require < module name or path >Requer um módulo de nó antes da execução
ts-node --cwd < path/to/directory >Comporte -se como se fosse invocado neste diretório de trabalho
Padrão: process.cwd()
Ambiente: TS_NODE_CWD
ts-node --emit Emite arquivos de saída no diretório .ts-node . Requer --compilerHost
Padrão: false
Ambiente: TS_NODE_EMIT
ts-node --scope Compilador de escopo para arquivos no scopeDir . Qualquer coisa fora deste diretório é ignorada.
Padrão: false
Ambiente: TS_NODE_SCOPE
ts-node --scopeDir < path/to/directory > Diretório dentro do qual o compilador é limitado quando scope está ativado.
Padrão: Primeiro de: tsconfig.json "rootdir", se especificado, diretório contendo tsconfig.json , ou cwd se nenhum tsconfig.json estiver carregado.
Ambiente: TS_NODE_SCOPE_DIR
Substitua o tipo de módulo de determinados arquivos, ignorando o campo package.json "type" . Consulte as substituições do tipo de módulo para obter detalhes.
Padrão: obeys package.json "type" e tsconfig.json "module"
Só pode ser especificado via tsconfig.json ou API.
TS_NODE_HISTORY= < path/to/history/file > ts-nodeArquivo de caminho para o histórico para repl
Padrão: ~/.ts_node_repl_history
ts-node --noExperimentalReplAwait Desative o nível superior aguardando em Repl. Equivalente ao nó --no-experimental-repl-await
Padrão: ativado se a versão do TypeScript for 3.8 ou superior e o destino for ES2018 ou superior.
Ambiente: TS_NODE_EXPERIMENTAL_REPL_AWAIT SET false para desativar
Habilite ganchos experimentais que reformulam as importações e requerem chamadas para suportar:
import "./foo.js" executará foo.ts Atualmente, as seguintes extensões serão mapeadas:.js para .ts , .tsx ou .jsx.cjs para .cts.mjs para .mts.jsx para .tsxNo futuro, este gancho também apoiará:
baseUrl , pathsrootDirsoutDir para mapeamentos rootDir para projetos compostos e monoreposPara detalhes, consulte #1514.
Padrão: false , mas provavelmente será ativado por padrão em uma versão futura
Só pode ser especificado via tsconfig.json ou API.
ts-node --experimentalSpecifierResolution node Como --experimental-specifier-resolution de Node, mas também pode ser definido em seu tsconfig.json por conveniência. Requer que esm seja ativado.
Padrão: explicit
A API inclui opções adicionais não mostradas aqui.
O suporte do SWC está interno através do sinalizador --swc ou "swc": true TSConfig.
O SWC é um transpiler compatível com o TypeScript implementado no Rust. Isso o torna uma ordem de magnitude mais rápida que a baunilha transpileOnly .
Para usá -lo, primeiro instale @swc/core ou @swc/wasm . Se estiver usando importHelpers , também instale @swc/helpers . Se target for menor que "ES2015" e usando funções async / await ou gerador, também instale regenerator-runtime .
npm i -D @swc/core @swc/helpers regenerator-runtime Em seguida, adicione o seguinte ao seu tsconfig.json .
{
"ts-node" : {
"swc" : true
}
}O SWC usa
@swc/helpersem vez detslib. Se você ativouimportHelpers, também deve instalar@swc/helpers.
O TypeScript é quase sempre escrito usando a sintaxe import moderna, mas também é transformada antes de ser executada pelo tempo de execução subjacente. Você pode optar por se transformar em Commonjs ou preservar a sintaxe import nativa, usando o suporte a ESM nativo do Node. A configuração é diferente para cada um.
Aqui está uma breve comparação dos dois.
| Commonjs | Módulos nativos do ecmascript |
|---|---|
Escreva sintaxe import nativa | Escreva sintaxe import nativa |
Transforma import em require() | Não transforma import |
| Node executa scripts usando o carregador clássico do Commonjs | O nó executa scripts usando o novo carregador ESM |
Use qualquer um de:ts-nodenode -r ts-node/registerNODE_OPTIONS="ts-node/register" noderequire('ts-node').register({/* options */}) | Use qualquer um de:ts-node --esmts-node-esmDefinir "esm": true em tsconfig.jsonnode --loader ts-node/esmNODE_OPTIONS="--loader ts-node/esm" node |
Transformar em CommonJs é tipicamente mais simples e mais amplamente suportado porque é mais antigo. Você deve remover "type": "module" do package.json e definir "module": "CommonJS" em tsconfig.json .
{
// This can be omitted; commonjs is the default
"type" : "commonjs"
} {
"compilerOptions" : {
"module" : "CommonJS"
}
} Se você precisar manter "module": "ESNext" para tsc , Webpack ou outra ferramenta de construção, poderá definir uma substituição para o nó TS.
{
"compilerOptions" : {
"module" : "ESNext"
} ,
"ts-node" : {
"compilerOptions" : {
"module" : "CommonJS"
}
}
} Os ganchos do carregador ESM do Node são experimentais e sujeitos a alterações. O suporte ESM do TS-Node é o mais estável possível, mas depende de APIs que o nó pode e será divulgado em novas versões do nó. Portanto, não é recomendado para produção.
Para uso completo, limitações e para fornecer feedback, consulte #1007.
Você deve definir "type": "module" no package.json e "module": "ESNext" em tsconfig.json .
{
"type" : "module"
} {
"compilerOptions" : {
"module" : "ESNext" // or ES2015, ES2020
} ,
"ts-node" : {
// Tell ts-node CLI to install the --loader automatically, explained below
"esm" : true
}
} Você também deve garantir que o nó seja aprovado --loader . A CLI do TS Node fará isso automaticamente com nossa opção esm .
NOTA:
--esmdeve gerar um processo filho para aprová -lo--loader. Isso pode alterar se o nó adicionar a capacidade de instalar os conectores do carregador no processo atual.
# pass the flag
ts-node --esm
# Use the convenience binary
ts-node-esm
# or add `"esm": true` to your tsconfig.json to make it automatic
ts-nodeSe você não estiver usando nossa CLI, passe o sinalizador do carregador para o nó.
node --loader ts-node/esm ./index.ts
# Or via environment variable
NODE_OPTIONS= " --loader ts-node/esm " node ./index.ts O TS-Node usa configurações padrão sensíveis para reduzir o placa de caldeira enquanto ainda respeita tsconfig.json , se você tiver um. Se você não tiver certeza de qual configuração é usada, poderá registrá-lo com ts-node --showConfig . Isso é semelhante ao tsc --showConfig mas inclui opções "ts-node" também.
O TS-Node também respeita a sua versão typescript , mas as instalações globais de Fallback do typescript de instalação global. Se você não tiver certeza de quais versões são usadas, ts-node -vv os registrará.
$ ts-node -vv
ts-node v10.0.0
node v16.1.0
compiler v4.2.2
$ ts-node --showConfig
{
" compilerOptions " : {
" target " : " es6 " ,
" lib " : [
" es6 " ,
" dom "
],
" rootDir " : " ./src " ,
" outDir " : " ./.ts-node " ,
" module " : " commonjs " ,
" moduleResolution " : " node " ,
" strict " : true,
" declaration " : false,
" sourceMap " : true,
" inlineSources " : true,
" types " : [
" node "
],
" stripInternal " : true,
" incremental " : true,
" skipLibCheck " : true,
" importsNotUsedAsValues " : " error " ,
" inlineSourceMap " : false,
" noEmit " : false
},
" ts-node " : {
" cwd " : " /d/project " ,
" projectSearchDir " : " /d/project " ,
" require " : [],
" project " : " /d/project/tsconfig.json "
}
} É importante diferenciar entre erros do nó TS, erros do compilador TypeScript e erros do node . Também é importante entender quando os erros são causados por um erro de tipo em seu código, um bug no seu código ou uma falha na sua configuração.
TSError Os erros de tipo do compilador são jogados como um TSError . Estes são os mesmos que os erros que você recebe do tsc .
SyntaxError Qualquer erro que não seja um TSError é do Node.js (por exemplo, SyntaxError ) e não pode ser corrigido por typingscript ou TS Node. Estes são bugs em seu código ou configuração.
Sua versão do node pode não suportar toda a sintaxe JavaScript suportada pelo TypeScript. O compilador deve transformar essa sintaxe via "Downleveling", que é controlado pela opção TSCONFIG "target" . Caso contrário, seu código compilará bem, mas o nó lançará um SyntaxError .
Por exemplo, node 12 não entende o ?. Operador de encadeamento opcional. Se você usar "target": "esnext" , a seguinte sintaxe datilografada:
const bar : string | undefined = foo ?. bar ;irá compilar neste JavaScript:
const a = foo ?. bar ; Quando você tenta executar esse código, o nó 12 lançará um SyntaxError . Para corrigir isso, você deve mudar para "target": "es2019" ou mais baixo transformam as transformadas do TypeScript ?. em algo que node pode entender.
ERR_REQUIRE_ESM Este erro é lançado pelo nó quando um módulo é require() d, mas o Node acredita que deve ser executado como ESM nativo. Isso pode acontecer por alguns motivos:
webpack.config.ts , que deve ser executado como Commonjs.ctsERR_UNKNOWN_FILE_EXTENSIONEste erro é lançado pelo nó quando um módulo possui uma extensão de arquivo não reconhecida ou nenhuma extensão e está sendo executada como ESM nativo. Isso pode acontecer por alguns motivos:
mocha .ts-node-esm , ts-node --esm ou Adicione "ts-node": {"esm": true} ao seu tsconfig.json. Documentoswebpack.config.ts , que deve ser executado como Commonjs.cts O nó TS não carrega ansiosamente files , include ou exclude por padrão. Isso ocorre porque a grande maioria dos projetos não usa todos os arquivos em um diretório de projeto (por exemplo, Gulpfile.ts , tempo de execução vs testes) e analisar todos os arquivos para os tipos diminuem o tempo de inicialização. Em vez disso, o nó TS começa com o arquivo de script (por exemplo ts-node index.ts ) e o TypeScript resolve dependências com base em importações e referências.
Ocasionalmente, essa otimização leva a tipos ausentes. Felizmente, existem outras maneiras de incluí -las na esceca de digitação.
Para definições globais, você pode usar a opção typeRoots Compiler. Isso requer que suas definições de tipo sejam estruturadas como pacotes de tipos (não arquivos de definição de texto digital solto). Mais detalhes sobre como isso funciona pode ser encontrado no Manual do TypeScript.
Exemplo tsconfig.json :
{
"compilerOptions" : {
"typeRoots" : [ "./node_modules/@types" , "./typings" ]
}
}Exemplo de estrutura do projeto:
<project_root>/
-- tsconfig.json
-- typings/
-- <module_name>/
-- index.d.ts
Exemplo de arquivo de declaração de módulo:
declare module '<module_name>' {
// module definitions go here
} Para definições de módulos, você pode usar paths :
{
"compilerOptions" : {
"baseUrl" : "." ,
"paths" : {
"custom-module-type" : [ "types/custom-module-type" ]
}
}
} Outra opção são as diretrizes de luta tripla. Isso pode ser útil se você preferir não alterar suas compilerOptions ou estruturar suas definições de tipo para typeRoots . Abaixo está um exemplo de uma diretiva tripla-slash como um caminho relativo em seu projeto:
/// <reference path="./types/lib_greeter" />
import { Greeter } from "lib_greeter"
const g = new Greeter ( ) ;
g . sayHello ( ) ; Se nenhum dos acima funcionar e você deverá usar files , include ou exclude , ativar nossa opção files .
Ao executar o TypeScript com npx ou yarn dlx , o código reside em um diretório temporário node_modules .
O conteúdo dos node_modules é ignorado por padrão. Se a execução falhar, ative skipIgnore .
Esses truques tornarão o nó TS mais rápido.
Muitas vezes, é melhor digitar como parte de seus testes ou linha. Você pode executar tsc --noEmit para fazer isso. Nesses casos, o nó TS pode pular o TypeChecking, tornando-o muito mais rápido.
Para pular o TypeChecking no nó TS, faça um dos seguintes:
transpileOnly para pular o TypeChecking sem o SWC Se você absolutamente precisar digitar no nó TS:
require() que pode desencadear o TypeChecking repetido; prefira import--files ; Pode -se ser mais rápido, dependendo do seu projetotsc --showConfig ; Verifique se todos os arquivos executados estão incluídosskipLibChecktypes para evitar o carregamento desnecessário @types O nó TS funciona registrando ganchos para extensões .ts , .tsx , .js e/ou .jsx .
node de baunilha carrega .js lendo o código do disco e executando -o. Nosso gancho é executado no meio, transformando o código do TypeScript em JavaScript e passando o resultado para node para execução. Essa transformação respeitará seu tsconfig.json como se você tivesse compilado via tsc .
Também registramos alguns outros ganchos para aplicar o SourCemaps para empilhar traços e remapear de importações .js para .ts .
O nó TS transforma certos arquivos e ignora outros. Nós nos referimos a esse mecanismo como "escopo". Existem várias opções para configurar o escopo, para que o TS Node transforme apenas os arquivos em seu projeto.
Aviso:
Um arquivo ignorado ainda pode ser executado pelo Node.JS. Ignorar um arquivo significa que não o transformamos do TypeScript em JavaScript, mas não impede a execução.
Se um arquivo exigir transformação, mas for ignorado, o nó poderá deixar de resolvê -lo ou tentar executá -lo como Javascript de baunilha. Isso pode causar erros de sintaxe ou outras falhas, porque o nó não entende a sintaxe do tipo de tipscript nem os recursos do ECMAScript de ponta de sangramento.
.js e .jsx são transformados apenas quando allowJs está ativado.
.tsx e .jsx são transformados apenas quando jsx está ativado.
Aviso:
Quando o nó TS é usado com
allowJs, todos os arquivos JavaScript não ignorados são transformados pelo nó TS.
node_modules Por padrão, o TS-Node evita a compilação de arquivos em /node_modules/ por três motivos:
Se você precisar importar o TypeScript não compilado em node_modules , use --skipIgnore ou TS_NODE_SKIP_IGNORE para ignorar essa restrição.
Se já existir um arquivo JavaScript compilado com o mesmo nome que um arquivo de texto digital, o arquivo TypeScript será ignorado. O TS-Node importará o JavaScript pré-compilado.
Para forçar o nó TS a importar a fonte do TypeScript, não o JavaScript pré-compilado, use --preferTsExts .
Nossas opções de scope e scopeDir limitarão a transformação em arquivos em um diretório.
Nossa opção ignore irá ignorar os arquivos que correspondem a uma ou mais expressões regulares.
Você pode usar o nó TS juntamente com o TSCONFIG-PATHS para carregar módulos de acordo com a seção paths em tsconfig.json .
{
"ts-node" : {
// Do not forget to `npm i -D tsconfig-paths`
"require" : [ "tsconfig-paths/register" ]
}
} O Manual Oficial do Typescript explica o objetivo pretendido para "paths" em "sinalizadores adicionais de resolução do módulo".
O compilador TypeScript possui um conjunto de sinalizadores adicionais para informar o compilador de transformações que devem acontecer às fontes para gerar a saída final.
É importante observar que o compilador não executará nenhuma dessas transformações; Ele apenas usa essas informações para orientar o processo de resolução de um módulo importar para seu arquivo de definição.
Isso significa que "paths" têm como objetivo descrever os mapeamentos que a ferramenta de construção ou o tempo de execução já executa, não para informar a ferramenta de construção ou o tempo de execução como resolver módulos. Em outras palavras, eles pretendem escrever nossas importações de uma maneira que node já entende. Por esse motivo, o TS-Node não modifica o comportamento de resolução do módulo do node para implementar os mapeamentos de "paths" .
Alguns projetos exigem um compilador de texto patchedado que adiciona recursos adicionais. Por exemplo, ttypescript e ts-patch adicionam a capacidade de configurar transformadores personalizados. Estes são substituições de entrega para o módulo typescript e implementam a mesma API.
Por exemplo, para usar ttypescript e ts-transformer-keys , adicione-o ao seu tsconfig.json :
{
"ts-node" : {
// This can be omitted when using ts-patch
"compiler" : "ttypescript"
} ,
"compilerOptions" : {
// plugin configuration is the same for both ts-patch and ttypescript
"plugins" : [
{ "transform" : "ts-transformer-keys/transformer" }
]
}
} O nó TS suporta transpilers de terceiros como plugins. Transpilers como o SWC podem transformar o TypeScript em JavaScript muito mais rápido que o compilador datilografado. Você ainda se beneficiará da descoberta automática tsconfig.json da TS-Node, suporte a SourCemap e CLI global de nó TS. Os plugins derivam automaticamente uma configuração apropriada do seu tsconfig.json existente, que simplifica o Boilerplate do Projeto.
Qual é a diferença entre um compilador e um transpiler?
Para nossos propósitos, um compilador implementa a API do TypeScript e pode executar a esceca do Type. Um transpiler de terceiros não. Ambos transformam o TypeScript em JavaScript.
A opção transpiler permite o uso de plug-ins de transpiler de terceiros com nó TS. transpiler deve receber o nome de um módulo que pode ser require() d. O plug-in swc integrado é exposto como ts-node/transpilers/swc .
Por exemplo, para usar um hipotético " @cspotcode/fast-ts-compiler", primeiro instale-o no seu projeto: npm install @cspotcode/fast-ts-compiler
Em seguida, adicione o seguinte ao seu tsconfig:
{
"ts-node" : {
"transpileOnly" : true ,
"transpiler" : "@cspotcode/fast-ts-compiler"
}
}Para escrever seu próprio plug -in de transpiler, verifique nossos documentos da API.
Os plugins são require() d por nó TS, para que possam ser um script local ou um módulo de nó publicado no NPM. O módulo deve exportar uma função create descrita por nossa interface TranspilerModule . create é chamado pelo nó TS na inicialização para criar uma ou mais instâncias de transpiler. As instâncias são usadas para transformar o TypeScript em JavaScript.
Para um exemplo de funcionamento, confira nosso plugin SWC agrupado: https://github.com/typestrong/ts-node/blob/main/src/transpilers/swc.ts
Sempre que possível, é recomendável usar o modo
NodeNextouNode16do TypeScript, em vez das opções descritas nesta seção. Definir"module": "NodeNext"e o uso da extensão do arquivo.ctsdeve funcionar bem para a maioria dos projetos.
Ao decidir como um arquivo deve ser compilado e executado-como Commonjs ou módulo nativo do ECMAScript-o Nó TS corresponde ao comportamento node e tsc . Isso significa que os arquivos do TypeScript são transformados de acordo com sua opção "module" tsconfig.json e executados de acordo com as regras do Node para o package.json "type" . Defina "module": "NodeNext" e tudo deve funcionar.
Em casos raros, pode ser necessário substituir esse comportamento para alguns arquivos. Por exemplo, algumas ferramentas leem um name-of-tool.config.ts e exigem que esse arquivo seja executado como Commonjs. Se você possui package.json configurado com "type": "module" e tsconfig.json com "module": "esnext" , a configuração é o ecmas nativo por padrão e levantará um erro. Você precisará forçar a configuração e quaisquer scripts de suporte para executar como Commonjs.
Nessas situações, nossa opção moduleTypes pode substituir determinados arquivos a serem comuns ou ESM. A substituição semelhante é possível usando extensões de arquivo .mts , .cts , .cjs e .mjs . moduleTypes atingem o mesmo efeito para arquivos .ts e .js e também substitui sua configuração "module" tsconfig.json apropriadamente.
O exemplo a seguir informa ao TS-Node para executar uma configuração WebPack como Commonjs:
{
"ts-node" : {
"transpileOnly" : true ,
"moduleTypes" : {
"webpack.config.ts" : "cjs" ,
// Globs are also supported with the same behavior as tsconfig "include"
"webpack-config-scripts/**/*" : "cjs"
}
} ,
"compilerOptions" : {
"module" : "es2020" ,
"target" : "es2020"
}
} Cada tecla é um padrão global com a mesma sintaxe que a matriz "include" do TSCONFIG. Quando vários padrões correspondem ao mesmo arquivo, o último padrão tem precedência.
cjs substitui os arquivos para compilar e executar como Commonjs.esm substitui os arquivos para compilar e executar como módulos nativos do ECMAScript.package redefine qualquer um dos itens acima para o comportamento padrão, que obedece package.json "type" e tsconfig.json "module" opções. Os arquivos com um tipo de módulo substituído são transformados com as mesmas limitações que isolatedModules . Isso afetará apenas casos raros, como o uso de const enum s com preserveConstEnums desativados.
Esse recurso destina -se a facilitar cenários em que não são possíveis cenários em que compilerOptions normais e configuração package.json . Por exemplo, um webpack.config.ts não pode receber seu próprio package.json para substituir "type" . Sempre que possível, você deve favorecer o uso de configurações tradicionais package.json e tsconfig.json .
A API completa do TS-Node está documentada aqui: API Docs
Aqui estão alguns destaques do que você pode realizar:
create() cria o serviço de compilador do TS-Node sem registrar nenhum gancho.createRepl() Cria uma instância do nosso serviço Repl, para que você possa criar seus próprios REPLs de TypeScript.createEsmHooks() cria nossos ganchos de carregador ESM, adequados para composição com outros carregadores ou aumentando com recursos adicionais.O TS-Node se concentra em adicionar suporte de primeira classe ao nó. Assistir a arquivos e recarregamentos de código estão fora de escopo do projeto.
Se você deseja reiniciar o processo de ts-node na alteração do arquivo, as ferramentas Node.js existentes, como Nodemon, OnChange e Node-Dev.
Há também ts-node-dev , uma versão modificada do node-dev usando ts-node para compilação que reiniciará o processo em alteração de arquivo. Observe que ts-node-dev é incompatível com o nosso carregador de ESM nativo.
Supondo que você esteja configurando a Ava através do seu package.json , adicione uma das seguintes configurações.
Use esta configuração se o seu package.json não tiver "type": "module" .
{
"ava" : {
"extensions" : [
"ts"
] ,
"require" : [
"ts-node/register"
]
}
} Essa configuração é necessária se o seu package.json tiver "type": "module" .
{
"ava" : {
"extensions" : {
"ts" : "module"
} ,
"nonSemVerExperiments" : {
"configurableModuleFormat" : true
} ,
"nodeArguments" : [
"--loader=ts-node/esm"
]
}
} O suporte de nó TS está embutido para gole.
# Create a `gulpfile.ts` and run `gulp`.
gulpVeja também: https://gulpjs.com/docs/en/getting-started/javascript-and-gulpfiles#transpilation
Crie uma nova configuração do Node.js e adicione -r ts-node/register aos "parâmetros do nó".
NOTA: Se você estiver usando o argumento da linha de comando --project <tsconfig.json> conforme as opções de configuração, e deseja aplicar esse mesmo comportamento ao lançar no Intellij, especifique em "Variáveis do ambiente": TS_NODE_PROJECT=<tsconfig.json> .
mocha --require ts-node/register --extensions ts,tsx --watch --watch-files src ' tests/**/*.{ts,tsx} ' [...args]Ou especifique opções através do seu arquivo de configuração do Mocha.
{
// Specify "require" for CommonJS
"require" : "ts-node/register" ,
// Specify "loader" for native ESM
"loader" : "ts-node/esm" ,
"extensions" : [ "ts" , "tsx" ] ,
"spec" : [
"tests/**/*.spec.*"
] ,
"watch-files" : [
"src"
]
}Veja também: https://mochajs.org/#configuring-mocha-nodejs
mocha --require ts-node/register --watch-extensions ts,tsx " test/**/*.{ts,tsx} " [...args] NOTA: --watch-extensions é usado apenas no modo --watch .
ts-node node_modules/tape/bin/tape [...args] Crie uma nova configuração de depuração do Node.js, adicione -r ts-node/register ao nó args e mova o program para a lista args (para que o código VS não procure outFiles ).
{
"configurations" : [ {
"type" : "node" ,
"request" : "launch" ,
"name" : "Launch Program" ,
"runtimeArgs" : [
"-r" ,
"ts-node/register"
] ,
"args" : [
"${workspaceFolder}/src/index.ts"
]
} ] ,
} NOTA: Se você estiver usando o argumento da linha de comando --project <tsconfig.json> , conforme as opções de configuração, e deseja aplicar esse mesmo comportamento ao iniciar o código VS, adicione uma tecla "Env" à configuração de lançamento: "env": { "TS_NODE_PROJECT": "<tsconfig.json>" }
Em muitos casos, a definição NODE_OPTIONS permitirá ts-node em outras ferramentas de nós, processos filhos e threads de trabalhadores.
NODE_OPTIONS= " -r ts-node/register "Ou, se você precisar de suporte nativo de ESM:
NODE_OPTIONS= " --loader ts-node/esm " Isso informa a todos os processos de nó que recebem essa variável de ambiente para instalar os ganchos do ts-node antes de executar outro código.
O nó TS é licenciado sob a licença do MIT. Mit
O nó TS inclui o código-fonte do Node.js, licenciado sob a licença do MIT. Informações de licença Node.js
O nó TS inclui o código-fonte do compilador TypeScript, licenciado sob a licença Apache 2.0. Informações da licença do TypeScript
