ts node
1.0.0
Exécution de typeScript et remplacez pour Node.js, avec MAP source et support ESM natif.
La dernière documentation peut également être trouvée sur notre site Web: https://typestrong.org/ts-node
nodeTSErrorSyntaxErrorERR_REQUIRE_ESMERR_UNKNOWN_FILE_EXTENSIONnode_modulesTS-Node est un moteur d'exécution TypeScript et remplace pour node.js.
Il transforme TypeScript en JavaScript, vous permettant d'exécuter directement TypeScript sur node.js sans précompir. Ceci est accompli en accrochant les API de chargement du module de Node, ce qui permet de l'utiliser de manière transparente aux côtés d'autres outils et bibliothèques Node.js.
tsconfig.json ARNCONFIG
# 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 Astuce: l'installation de modules localement vous permet de contrôler et de partager les versions via package.json . TS-Node résoudra toujours le compilateur à partir de cwd avant de vérifier par rapport à sa propre installation.
# 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 Pour écrire des scripts avec une portabilité maximale, spécifiez des options dans votre tsconfig.json et omettez-les à partir du shebang.
#!/usr/bin/env ts-node
// ts-node options are read from tsconfig.json
console . log ( "Hello, world!" ) L'inclusion d'options dans le shebang nécessite le drapeau env -S , qui est disponible sur les versions récentes d' env . (compatibilité)
#!/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 Pour tester votre version d' env pour la compatibilité avec -S :
# Note that these unusual quotes are necessary
/usr/bin/env --debug ' -S echo foo bar ' Vous pouvez enregistrer le nœud TS sans utiliser notre CLI: node -r ts-node/register et node --loader ts-node/esm
Dans de nombreux cas, la définition NODE_OPTIONS permettra ts-node dans d'autres outils de nœud, les processus enfants et les threads de travail. Cela peut être combiné avec d'autres drapeaux de nœud.
NODE_OPTIONS= " -r ts-node/register --no-warnings " node ./index.tsOu, si vous avez besoin de support ESM natif:
NODE_OPTIONS= " --loader ts-node/esm " Cela indique à tous les processus de nœud qui reçoivent cette variable d'environnement pour installer les crochets de ts-node avant d'exécuter un autre code.
Si vous invoquez directement le nœud, vous pouvez éviter la variable d'environnement et passer ces drapeaux au nœud.
node --loader ts-node/esm --inspect ./index.ts Vous pouvez exiger du nœud TS et enregistrer le chargeur pour les exigences futures en utilisant require('ts-node').register({ /* options */ }) .
Consultez notre API pour plus de fonctionnalités.
TS-Node prend en charge une variété d'options qui peuvent être spécifiées via tsconfig.json , comme indicateurs CLI, en tant que variables d'environnement, ou par programme.
Pour une liste complète, voir les options.
Les drapeaux CLI à nœuds TS doivent être avant le script de point d'entrée. Par exemple:
$ ts-node --project tsconfig-dev.json say-hello.ts Ronald
Hello, Ronald ! TS-Node trouve et charge automatiquement tsconfig.json . La plupart des options de nœud TS peuvent être spécifiées dans un objet "ts-node" en utilisant leurs noms programmatiques de camelcase. Nous recommandons cela car cela fonctionne même lorsque vous ne pouvez pas passer des drapeaux CLI, tels que node --require ts-node/register et lorsque vous utilisez des shebangs.
Utilisez --skipProject pour sauter le chargement du tsconfig.json . Utilisez --project pour spécifier explicitement le chemin d'accès à un tsconfig.json .
Lors de la recherche, il est résolu en utilisant le même comportement de recherche que tsc . Par défaut, cette recherche est effectuée par rapport au script d'entrée. Dans --cwdMode ou si aucun point d'entrée n'est spécifié - par exemple lors de l'utilisation du REPL - la recherche est effectuée par rapport à --cwd / process.cwd() .
Vous pouvez utiliser cet exemple de configuration comme point de départ:
{
// 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
}
}Notre schéma JSON groupé répertorie toutes les options compatibles.
@ tsconfig / bases maintient les configurations recommandées pour plusieurs versions de nœuds. En tant que commodité, celles-ci sont regroupées avec des nœuds TS.
{
"extends" : "ts-node/node16/tsconfig.json" ,
// Or install directly with `npm i -D @tsconfig/node16`
"extends" : "@tsconfig/node16/tsconfig.json" ,
} Si aucun tsconfig.json n'est chargé à partir du disque, TS-node utilisera les plus récentes par défaut recommandés à partir de @ tsconfig / bases compatibles avec votre node et les versions typescript . Avec le dernier node et typescript , il s'agit @tsconfig/node16 .
Les anciennes versions de typescript sont incompatibles avec @tsconfig/node16 . Dans ces cas, nous utiliserons une ancienne configuration par défaut.
En cas de doute, ts-node --showConfig enregistrera la configuration utilisée, et ts-node -vv enregistrera les versions node et typescript .
node Les drapeaux node doivent être transmis directement au node ; Ils ne peuvent pas être transmis au binaire à nœud TS et ils ne peuvent pas être spécifiés dans tsconfig.json
Nous vous recommandons d'utiliser la variable d'environnement NODE_OPTIONS pour passer les options à node .
NODE_OPTIONS= ' --trace-deprecation --abort-on-uncaught-exception ' ts-node ./index.ts Alternativement, vous pouvez invoquer directement node et installer TS-node via --require / -r
node --trace-deprecation --abort-on-uncaught-exception -r ts-node/register ./index.ts Tous les drapeaux de ligne de commande prennent en charge --camelCase et --hyphen-case .
La plupart des options peuvent être déclarées dans votre tsconfig.json: configuration via tsconfig.json
ts-node prend en charge --print ( -p ), --eval ( -e ), --require ( -r ) et --interactive ( -i ) similaire au Node.js CLI.
ts-node prend en charge --project et --showConfig similaire à la CLI TSC.
Les variables d'environnement, le cas échéant, sont dans ALL_CAPS
ts-node --helpImprime le texte d'aide
ts-node -v
ts-node -vvv Imprime la version. -vv inclut les versions de compilateur de nœud et de type. -vvv comprend des chemins absolus vers les installations TS-node et TypeScript.
ts-node -e < typescript code >
# Example
ts-node -e ' console.log("Hello world!") 'Évaluer le code
ts-node -p -e < typescript code >
# Example
ts-node -p -e ' "Hello world!" ' Résultat d'impression de --eval
ts-node -iOuvre le REPL même si Stdin ne semble pas être un terminal
ts-node --esm
ts-node-esmBootstrap avec le chargeur ESM, permettant une prise en charge ESM complète
ts-node -P < path/to/tsconfig >
ts-node --project < path/to/tsconfig >Chemin vers le fichier tsconfig.
Remarquez la majuscule -P . Ceci est différent de l'option tsc -p/--project .
Environnement: TS_NODE_PROJECT
ts-node --skipProjectSauter la résolution et le chargement du projet
Par défaut: false
Environnement: TS_NODE_SKIP_PROJECT
ts-node -c
ts-node --cwdMode
ts-node-cwdRésoudre la configuration par rapport au répertoire actuel au lieu du répertoire du script de point d'entrée
ts-node -O < json compilerOptions >
ts-node --compilerOptions < json compilerOptions >Objet JSON à fusionner avec des options de compilateur
Environnement: TS_NODE_COMPILER_OPTIONS
ts-node --showConfig Imprimer tsconfig.json résolu, y compris les options ts-node , et sortir
ts-node -T
ts-node --transpileOnly Utilisez transpileModule plus rapide de TypeScript
Par défaut: false
Environnement: TS_NODE_TRANSPILE_ONLY
ts-node --typeCheck En face de --transpileOnly
Par défaut: true
Environnement: TS_NODE_TYPE_CHECK
ts-node -H
ts-node --compilerHostUtilisez l'API de l'hôte du compilateur de TypeScript
Par défaut: false
Environnement: TS_NODE_COMPILER_HOST
ts-node --files Chargez files , include et exclude de tsconfig.json au démarrage. Cela peut éviter certains échecs de type typique. Voir les types manquants pour plus de détails.
Par défaut: false
Environnement: TS_NODE_FILES
ts-node -D < code,code >
ts-node --ignoreDiagnostics < code,code >Ignorez les avertissements dactylographiés par code de diagnostic
Environnement: TS_NODE_IGNORE_DIAGNOSTICS
ts-node -I < regexp matching ignored files >
ts-node --ignore < regexp matching ignored files >Remplacer les modèles de chemin pour sauter la compilation
Par défaut: /node_modules/
Environnement: TS_NODE_IGNORE
ts-node --skipIgnoreIgnorez les chèques
Par défaut: false
Environnement: TS_NODE_SKIP_IGNORE
ts-node -C < name >
ts-node --compiler < name >Spécifiez un compilateur TypeScript personnalisé
Par défaut: typescript
Environnement: TS_NODE_COMPILER
ts-node --swc Transplier avec SWC. Implique --transpileOnly
Par défaut: false
ts-node --transpiler < name >
# Example
ts-node --transpiler ts-node/transpilers/swcUtilisez un transpiler tiers et non typechking
ts-node --preferTsExtsRéorganiser les extensions de fichiers afin que les importations de dactylographie soient préférées
Par défaut: false
Environnement: TS_NODE_PREFER_TS_EXTS
ts-node --logErrorJournaux des erreurs de dactylographie à stderr au lieu de lancer des exceptions
Par défaut: false
Environnement: TS_NODE_LOG_ERROR
ts-node --prettyUtilisez un joli formateur de diagnostic
Par défaut: false
Environnement: TS_NODE_PRETTY
TS_NODE_DEBUG=true ts-nodeActiver la journalisation de débogage
ts-node -r < module name or path >
ts-node --require < module name or path >Nécessitent un module de nœud avant l'exécution
ts-node --cwd < path/to/directory >Se comporter comme invoqué dans ce répertoire de travail
Par défaut: process.cwd()
Environnement: TS_NODE_CWD
ts-node --emit Émettez des fichiers de sortie dans le répertoire .ts-node . Nécessite --compilerHost
Par défaut: false
Environnement: TS_NODE_EMIT
ts-node --scope Compilateur de gamme sur les fichiers dans scopeDir . Tout ce qui en dehors de ce répertoire est ignoré.
Par défaut: false
Environnement: TS_NODE_SCOPE
ts-node --scopeDir < path/to/directory > Répertoire dans lequel le compilateur est limité lorsque scope est activée.
Par défaut: premier de: tsconfig.json "rootdir" si spécifié, répertoire contenant tsconfig.json ou cwd si aucun tsconfig.json n'est chargé.
Environnement: TS_NODE_SCOPE_DIR
Remplacez le type de module de certains fichiers, en ignorant le champ package.json "type" . Voir les remplacements de type de module pour plus de détails.
Par défaut: obeys package.json "type" et tsconfig.json "module"
Ne peut être spécifié que via tsconfig.json ou API.
TS_NODE_HISTORY= < path/to/history/file > ts-nodeChemin vers l'historique Fichier pour REP
Par défaut: ~/.ts_node_repl_history
ts-node --noExperimentalReplAwait Désactiver l'attente de niveau supérieur en remplacement. Équivalent à la Node --no-experimental-repl-await
Par défaut: activé si la version TypeScript est 3,8 ou plus et la cible est ES2018 ou plus.
Environnement: TS_NODE_EXPERIMENTAL_REPL_AWAIT set false à Désactiver
Activer les crochets expérimentaux qui referment les importations et nécessitent des appels pour prendre en charge:
import "./foo.js" exécutera foo.ts Actuellement, les extensions suivantes seront cartographiées:.js à .ts , .tsx ou .jsx.cjs à .cts.mjs à .mts.jsx à .tsxÀ l'avenir, ce crochet soutiendra également:
baseUrl , pathsrootDirsoutDir à rootDir pour les projets composites et monoreposPour plus de détails, voir # 1514.
Par défaut: false , mais sera probablement activé par défaut dans une future version
Ne peut être spécifié que via tsconfig.json ou API.
ts-node --experimentalSpecifierResolution node Comme --experimental-specifier-resolution de Node, mais peut également être défini dans votre tsconfig.json pour plus de commodité. Nécessite que esm soit activé.
Par défaut: explicit
L'API comprend des options supplémentaires non affichées ici.
La prise en charge SWC est intégrée via l'indicateur --swc ou l'option "swc": true TSConfig.
SWC est un transpiler compatible de typeScript implémenté en rouille. Cela en fait un ordre de grandeur plus rapide que la vanille transpileOnly .
Pour l'utiliser, installez d'abord @swc/core ou @swc/wasm . Si vous utilisez importHelpers , installez également @swc/helpers . Si target est inférieure à "ES2015" et en utilisant des fonctions async / await ou générateur, installez également regenerator-runtime .
npm i -D @swc/core @swc/helpers regenerator-runtime Ajoutez ensuite ce qui suit à votre tsconfig.json .
{
"ts-node" : {
"swc" : true
}
}SWC utilise
@swc/helpersau lieu detslib. Si vous avez activéimportHelpers, vous devez également installer@swc/helpers.
TypeScript est presque toujours écrit à l'aide de la syntaxe import moderne, mais il est également transformé avant d'être exécuté par l'exécution sous-jacente. Vous pouvez choisir de vous transformer en CommonJS ou de préserver la syntaxe import native, en utilisant le support ESM natif de Node. La configuration est différente pour chacun.
Voici une brève comparaison des deux.
| CommonJS | Modules ecmascript natifs |
|---|---|
Écrire une syntaxe import native | Écrire une syntaxe import native |
Transforme import en require() | Ne transforme pas import |
| Le nœud exécute des scripts à l'aide du chargeur CommonJS classique | Le nœud exécute des scripts à l'aide du nouveau chargeur ESM |
Utilisez l'un des:ts-nodenode -r ts-node/registerNODE_OPTIONS="ts-node/register" noderequire('ts-node').register({/* options */}) | Utilisez l'un des:ts-node --esmts-node-esmDéfinir "esm": true dans tsconfig.jsonnode --loader ts-node/esmNODE_OPTIONS="--loader ts-node/esm" node |
La transformation en CommonJS est généralement plus simple et plus largement prise en charge car elle est plus ancienne. Vous devez supprimer "type": "module" de package.json et définir "module": "CommonJS" dans tsconfig.json .
{
// This can be omitted; commonjs is the default
"type" : "commonjs"
} {
"compilerOptions" : {
"module" : "CommonJS"
}
} Si vous devez conserver "module": "ESNext" pour tsc , WebPack ou un autre outil de construction, vous pouvez définir un remplacement pour TS-Node.
{
"compilerOptions" : {
"module" : "ESNext"
} ,
"ts-node" : {
"compilerOptions" : {
"module" : "CommonJS"
}
}
} Les crochets ESM de la chargeur de Node sont expérimentaux et sujets à changement. La prise en charge ESM de TS-Node est aussi stable que possible, mais elle s'appuie sur les API que le nœud peut et rompra dans de nouvelles versions de nœud. Il n'est donc pas recommandé pour la production.
Pour l'utilisation complète, les limitations et pour fournir des commentaires, voir # 1007.
Vous devez définir "type": "module" dans package.json et "module": "ESNext" dans 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
}
} Vous devez également vous assurer que le nœud est passé --loader . La CLI à nœuds TS le fera automatiquement avec notre option esm .
Remarque:
--esmdoit engendrer un processus enfant pour le passer--loader. Cela peut changer si le nœud ajoute la possibilité d'installer des crochets de chargeur dans le processus actuel.
# 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-nodeSi vous n'utilisez pas notre CLI, passez le drapeau de chargeur au nœud.
node --loader ts-node/esm ./index.ts
# Or via environment variable
NODE_OPTIONS= " --loader ts-node/esm " node ./index.ts TS-Node utilise des configurations par défaut sensibles pour réduire la plaque de chauffeur tout en respectant tsconfig.json si vous en avez un. Si vous ne savez pas quelle configuration est utilisée, vous pouvez le enregistrer avec ts-node --showConfig . Ceci est similaire à tsc --showConfig mais inclut également les options "ts-node" .
TS-Node respecte également votre version typescript d'installation localement, mais les installations globales se replient vers le typescript à l'installation globalement. Si vous ne savez pas quelles versions sont utilisées, ts-node -vv les enregistrera.
$ 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 "
}
} Il est important de différencier les erreurs du nœud TS, les erreurs du compilateur TypeScript et les erreurs du node . Il est également important de comprendre quand les erreurs sont causées par une erreur de type dans votre code, un bogue dans votre code ou une faille dans votre configuration.
TSError Les erreurs de type du compilateur sont lancées sous forme de TSError . Ce sont les mêmes que les erreurs que vous obtenez de tsc .
SyntaxError Toute erreur qui n'est pas un TSError provient de Node.js (par exemple SyntaxError ), et ne peut pas être corrigée par TypeScript ou TS-node. Ce sont des bogues dans votre code ou votre configuration.
Votre version de node peut ne pas prendre en charge toutes les syntaxes JavaScript prises en charge par TypeScript. Le compilateur doit transformer cette syntaxe via le «niveau de descente», qui est contrôlé par l'option tsconfig "target" . Sinon, votre code se compilera bien, mais le nœud lancera une SyntaxError .
Par exemple, node 12 ne comprend pas le ?. Opérateur de chaînage en option. Si vous utilisez "target": "esnext" , alors la syntaxe de type suivante:
const bar : string | undefined = foo ?. bar ;compilera dans ce javascript:
const a = foo ?. bar ; Lorsque vous essayez d'exécuter ce code, Node 12 lancera une SyntaxError . Pour résoudre ce problème, vous devez passer à "target": "es2019" ou baisser donc les transformations de typeScript ?. dans quelque chose que node peut comprendre.
ERR_REQUIRE_ESM Cette erreur est lancée par nœud lorsqu'un module est require() d, mais le noeud estime qu'il devrait s'exécuter en tant que ESM natif. Cela peut arriver pour plusieurs raisons:
webpack.config.ts , qui doit être exécuté comme CommonJS.ctsERR_UNKNOWN_FILE_EXTENSIONCette erreur est lancée par nœud lorsqu'un module a une extension de fichier non reconnue, ou pas du tout d'extension, et est exécuté en tant que ESM natif. Cela peut arriver pour plusieurs raisons:
mocha .ts-node-esm , ts-node --esm , ou ajoutez "ts-node": {"esm": true} à votre tsconfig.json. Docswebpack.config.ts , qui doit être exécuté comme CommonJS.cts TS-Node ne charge pas avec impatience files , include ou exclude par défaut. En effet, une grande majorité de projets n'utilisent pas tous les fichiers dans un répertoire de projet (par exemple Gulpfile.ts , runtime vs tests) et analyser chaque fichier pour les types qui ralentissent le temps de démarrage. Au lieu de cela, TS-Node commence par le fichier de script (par exemple ts-node index.ts ) et TypeScript résout les dépendances en fonction des importations et des références.
Parfois, cette optimisation conduit à des types manquants. Heureusement, il existe d'autres moyens de les inclure dans la type de type.
Pour les définitions globales, vous pouvez utiliser l'option typeRoots Compiler. Cela nécessite que vos définitions de type soient structurées sous forme de packages de type (pas de fichiers de définition de type lâche). Plus de détails sur la façon dont cela fonctionne dans le manuel TypeScript.
Exemple tsconfig.json :
{
"compilerOptions" : {
"typeRoots" : [ "./node_modules/@types" , "./typings" ]
}
}Exemple de structure de projet:
<project_root>/
-- tsconfig.json
-- typings/
-- <module_name>/
-- index.d.ts
Exemple de fichier de déclaration de module:
declare module '<module_name>' {
// module definitions go here
} Pour les définitions de modules, vous pouvez utiliser paths :
{
"compilerOptions" : {
"baseUrl" : "." ,
"paths" : {
"custom-module-type" : [ "types/custom-module-type" ]
}
}
} Une autre option est les directives à triple slash. Cela peut être utile si vous préférez ne pas modifier vos compilerOptions ou structurer vos définitions de type pour typeRoots . Vous trouverez ci-dessous un exemple de directive à triple slash comme chemin relatif dans votre projet:
/// <reference path="./types/lib_greeter" />
import { Greeter } from "lib_greeter"
const g = new Greeter ( ) ;
g . sayHello ( ) ; Si aucune de ces fonctions ci-dessus ne fonctionne et que vous devez utiliser files , include ou exclude , activez l'option de nos files .
Lors de l'exécution de TypeScript avec npx ou yarn dlx , le code réside dans un répertoire node_modules temporaire.
Le contenu de node_modules est ignoré par défaut. Si l'exécution échoue, activez skipIgnore .
Ces astuces rendront le nœud TS plus rapidement.
Il est souvent préférable de TypeCheck dans le cadre de vos tests ou de votre libellé. Vous pouvez exécuter tsc --noEmit pour ce faire. Dans ces cas, le nœud TS peut ignorer la type de type, ce qui le rend beaucoup plus rapide.
Pour sauter la type type dans le nœud TS, effectuez l'une des éléments suivants:
transpileOnly de sauter la type de type sans SWC Si vous devez absolument TypeCheck dans TS-Node:
require() qui peut déclencher une typède répétée; Préférer import--files ; On peut être plus rapide en fonction de votre projettsc --showConfig ; Assurez-vous que tous les fichiers exécutés sont inclusskipLibChecktypes pour éviter de charger @types inutiles TS-Node fonctionne en enregistrant des crochets pour les extensions .ts , .tsx , .js et / ou .jsx .
node vanille charge .js en lisant le code du disque et en l'exécutant. Notre crochet s'exécute au milieu, transformant le code de TypeScript en JavaScript et passant le résultat au node pour exécution. Cette transformation respectera votre tsconfig.json comme si vous aviez compilé via tsc .
Nous enregistrons également quelques autres crochets pour appliquer Sourcemaps pour piétiner les traces et le remapt à partir des importations .js sur .ts .
TS-Node transforme certains fichiers et en ignore d'autres. Nous appelons ce mécanisme comme une «portée». Il existe différentes options pour configurer la portée, afin que TS-Node ne transforme que les fichiers dans votre projet.
Avertissement:
Un fichier ignoré peut toujours être exécuté par node.js. Ignorer un fichier signifie que nous ne le transformons pas de TypeScript en JavaScript, mais il n'empêche pas l'exécution.
Si un fichier nécessite une transformation mais est ignoré, le nœud peut ne pas le résoudre ou tenter de l'exécuter en tant que JavaScript Vanilla. Cela peut entraîner des erreurs de syntaxe ou d'autres échecs, car le nœud ne comprend pas la syntaxe de type TypeScript ni les fonctionnalités ECMAScript à bord de saignement.
.js et .jsx ne sont transformés que lorsque allowJs sont activés.
.tsx et .jsx ne sont transformés que lorsque jsx est activé.
Avertissement:
Lorsque le nœud TS est utilisé avec
allowJs, tous les fichiers JavaScript non désignés sont transformés par le nœud TS.
node_modules Par défaut, TS-Node évite de compiler des fichiers dans /node_modules/ pour trois raisons:
Si vous avez besoin d'importer des dactylistes non compilés dans node_modules , utilisez --skipIgnore ou TS_NODE_SKIP_IGNORE pour contourner cette restriction.
Si un fichier JavaScript compilé avec le même nom qu'un fichier TypeScript existe déjà, le fichier TypeScript sera ignoré. TS-Node importera le JavaScript précompilé.
Pour forcer le nœud TS à importer la source TypeScript, et non le JavaScript précompilé, utilisez --preferTsExts .
Nos options scope et scopeDir limiteront la transformation en fichiers dans un répertoire.
Notre option ignore ignorera les fichiers correspondant à une ou plusieurs expressions régulières.
Vous pouvez utiliser TS-Node avec TSConfig-Paths pour charger des modules en fonction de la section paths dans tsconfig.json .
{
"ts-node" : {
// Do not forget to `npm i -D tsconfig-paths`
"require" : [ "tsconfig-paths/register" ]
}
} Le manuel de type officiel explique l'objectif prévu des "paths" dans "des drapeaux de résolution de modules supplémentaires".
Le compilateur TypeScript a un ensemble de drapeaux supplémentaires pour informer le compilateur de transformations qui devraient arriver aux sources pour générer la sortie finale.
Il est important de noter que le compilateur n'effectuera aucune de ces transformations; Il utilise simplement ces informations pour guider le processus de résolution d'une importation de module dans son fichier de définition.
Cela signifie que "paths" sont destinés à décrire les mappages que l'outil de construction ou l'exécution effectue déjà , et non pour indiquer à l'outil de construction ou à l'exécution comment résoudre les modules. En d'autres termes, ils ont l'intention d'écrire nos importations d'une manière que node comprend déjà. Pour cette raison, TS-Node ne modifie pas le comportement de résolution du module de node pour implémenter les mappings "paths" .
Certains projets nécessitent un compilateur TypeScript corrigé qui ajoute des fonctionnalités supplémentaires. Par exemple, ttypescript et ts-patch ajoutent la possibilité de configurer les transformateurs personnalisés. Ce sont des remplacements d'allumage pour le module typescript Vanilla et implémentez la même API.
Par exemple, pour utiliser ttypescript et ts-transformer-keys , ajoutez-le à votre 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" }
]
}
} TS-Node prend en charge les transpilaires tiers en tant que plugins. Les transpiles tels que SWC peuvent transformer TypeScript en JavaScript beaucoup plus rapidement que le compilateur TypeScript. Vous bénéficierez toujours de la découverte automatique tsconfig.json de TS-Node, du support SourceMap et du CLI Global TS-Node. Les plugins dérivent automatiquement une configuration appropriée à partir de votre tsconfig.json existant qui simplifie le chauffeur de projet.
Quelle est la différence entre un compilateur et un transpiler?
Pour nos fins, un compilateur implémente l'API de TypeScript et peut effectuer des types de type. Un transpiler tiers ne le fait pas. Les deux transformations sont de typescript en javascript.
L'option transpiler permet d'utiliser des plugins de transpiler tiers avec le nœud TS. transpiler doit être donné le nom d'un module qui peut être require() d. Le plugin swc intégré est exposé sous forme de ts-node/transpilers/swc .
Par exemple, pour utiliser une hypothétique "@ cspotcode / fast-ts-compiler", installez-le d'abord dans votre projet: npm install @cspotcode/fast-ts-compiler
Puis ajoutez ce qui suit à votre tsconfig:
{
"ts-node" : {
"transpileOnly" : true ,
"transpiler" : "@cspotcode/fast-ts-compiler"
}
}Pour rédiger votre propre plugin Transpiler, consultez nos documents API.
Les plugins sont require() D par le nœud TS, de sorte qu'ils peuvent être un script local ou un module de nœud publié sur NPM. Le module doit exporter une fonction create décrite par notre interface TranspilerModule . create est invoqué par TS-Node au démarrage pour créer une ou plusieurs instances de transpiler. Les instances sont utilisées pour transformer TypeScript en JavaScript.
Pour un exemple de travail, consultez notre plugin SWC groupé: https://github.com/typestrong/ts-node/blob/main/src/transpilers/swc.ts
Dans la mesure du possible, il est recommandé d'utiliser le mode
NodeNextouNode16de TypeScript au lieu des options décrites dans cette section. Définir"module": "NodeNext"et l'utilisation de l'extension de fichier.ctsdevrait bien fonctionner pour la plupart des projets.
Lorsque vous décidez comment un fichier doit être compilé et exécuté - en tant que module CommonJS ou ECMAScript natif - TS-Node correspond node et au comportement tsc . Cela signifie que les fichiers TypeScript sont transformés en fonction de votre option tsconfig.json "module" et exécutés en fonction des règles de Node pour le champ package.json "type" . Définissez "module": "NodeNext" et tout devrait fonctionner.
Dans de rares cas, vous devrez peut-être remplacer ce comportement pour certains fichiers. Par exemple, certains outils lisent un name-of-tool.config.ts et nécessitent que le fichier s'exécute en tant que CommonJS. Si vous avez package.json configuré avec "type": "module" et tsconfig.json avec "module": "esnext" , la configuration est native ecmascript par défaut et augmentera une erreur. Vous devrez forcer la configuration et tout script de support pour exécuter en tant que CommonJS.
Dans ces situations, notre option moduleTypes peut remplacer certains fichiers pour être CommonJS ou ESM. Un remplacement similaire est possible en utilisant des extensions de fichiers .mts , .cts , .cjs et .mjs . moduleTypes réalisent le même effet pour les fichiers .ts et .js , et remplacent également votre configuration de "module" tsconfig.json de manière appropriée.
L'exemple suivant indique à TS-Node d'exécuter une configuration WebPack comme 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"
}
} Chaque clé est un modèle glob avec la même syntaxe que le tableau "include" de TSConfig. Lorsque plusieurs modèles correspondent au même fichier, le dernier modèle a priorité.
cjs remplace les fichiers pour compiler et exécuter en tant que CommonJS.esm remplace les fichiers pour compiler et exécuter en tant que modules ECMAScript natifs.tsconfig.json package réinitialise l'une des options de comportement par défaut ci-dessus, qui obéit aux options "type" et package.json "module" . Les fichiers avec un type de module remplacé sont transformés avec les mêmes limitations que isolatedModules . Cela n'affectera que de rares cas tels que l'utilisation de const enum S avec preserveConstEnums désactivés.
Cette fonctionnalité est destinée à faciliter les scénarios où la configuration normale compilerOptions et package.json n'est pas possible. Par exemple, un webpack.config.ts ne peut pas recevoir son propre package.json pour remplacer "type" . Dans la mesure du possible, vous devez favoriser l'utilisation des configurations traditionnelles package.json et tsconfig.json .
L'API complète de TS-Node est documentée ici: les documents API
Voici quelques points saillants de ce que vous pouvez accomplir:
create() Crée le service de compilateur de TS-Node sans enregistrer de crochets.createRepl() crée une instance de notre service de REP, afin que vous puissiez créer vos propres REPS alimentés par TypeScript.createEsmHooks() crée nos crochets ESM chargeur, adaptés à la composition avec d'autres chargeurs ou à l'augmentation de fonctionnalités supplémentaires.TS-Node se concentre sur l'ajout de prise en charge de type dactylographiée de première classe au nœud. Regarder les fichiers et les recharges de code sont hors de portée pour le projet.
Si vous souhaitez redémarrer le processus ts-node sur la modification du fichier, les outils Node.js existants tels que Nodemon, OnChange et Node-DEV fonctionnent.
Il existe également ts-node-dev , une version modifiée de node-dev utilisant ts-node pour la compilation qui redémarrera le processus sur le changement de fichier. Notez que ts-node-dev est incompatible avec notre chargeur ESM natif.
En supposant que vous configurez AVA via votre package.json , ajoutez l'une des configurations suivantes.
Utilisez cette configuration si votre package.json n'a pas "type": "module" .
{
"ava" : {
"extensions" : [
"ts"
] ,
"require" : [
"ts-node/register"
]
}
} Cette configuration est nécessaire si votre package.json a "type": "module" .
{
"ava" : {
"extensions" : {
"ts" : "module"
} ,
"nonSemVerExperiments" : {
"configurableModuleFormat" : true
} ,
"nodeArguments" : [
"--loader=ts-node/esm"
]
}
} Le support TS-Node est intégré à Gulp.
# Create a `gulpfile.ts` and run `gulp`.
gulpVoir aussi: https://gulpjs.com/docs/en/getting-started/javascript-and-gulpfiles#transpilation
Créez une nouvelle configuration Node.js et ajoutez -r ts-node/register aux «paramètres de nœud».
Remarque: Si vous utilisez l'argument de la ligne de commande --project <tsconfig.json> selon les options de configuration et que vous souhaitez appliquer ce même comportement lors du lancement dans IntelliJ, spécifiez sous "Variables d'environnement": TS_NODE_PROJECT=<tsconfig.json> .
mocha --require ts-node/register --extensions ts,tsx --watch --watch-files src ' tests/**/*.{ts,tsx} ' [...args]Ou spécifiez des options via votre fichier de configuration 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"
]
}Voir aussi: https://mochajs.org/#configuring-mocha-nodejs
mocha --require ts-node/register --watch-extensions ts,tsx " test/**/*.{ts,tsx} " [...args] Remarque: --watch-extensions est uniquement utilisée en mode --watch .
ts-node node_modules/tape/bin/tape [...args] Créez une nouvelle configuration de débogage Node.js, ajoutez -r ts-node/register dans les args de nœud et déplacez le program vers la liste args (afin que le code vs ne recherche pas outFiles ).
{
"configurations" : [ {
"type" : "node" ,
"request" : "launch" ,
"name" : "Launch Program" ,
"runtimeArgs" : [
"-r" ,
"ts-node/register"
] ,
"args" : [
"${workspaceFolder}/src/index.ts"
]
} ] ,
} Remarque: Si vous utilisez l'argument de la ligne de commande --project <tsconfig.json> selon les options de configuration et que vous souhaitez appliquer ce même comportement lors du lancement dans le code vs, ajoutez une clé "env" dans la configuration de lancement: "env": { "TS_NODE_PROJECT": "<tsconfig.json>" } .
Dans de nombreux cas, la définition NODE_OPTIONS permettra ts-node dans d'autres outils de nœud, les processus enfants et les threads de travail.
NODE_OPTIONS= " -r ts-node/register "Ou, si vous avez besoin de support ESM natif:
NODE_OPTIONS= " --loader ts-node/esm " Cela indique à tous les processus de nœud qui reçoivent cette variable d'environnement pour installer les crochets de ts-node avant d'exécuter un autre code.
TS-Node est sous licence sous la licence du MIT. Mit
TS-Node inclut le code source de Node.js qui est autorisé sous la licence MIT. Informations de licence Node.js
TS-Node inclut le code source du compilateur TypeScript qui est concédé sous licence Apache 2.0. Informations sur la licence de dactylographie
