ts blank space
v0.4.3
Un petit décapant de type JavaScript pur, rapide et pur qui utilise l'analyseur TypeScript officiel.
TypeScript entre :
class C < T > extends Array < T > implements I {
// ^^^ ^^^^^^^^^^^^^^^^
private field ! : string ;
// ^^^^^^^ ^^^^^^^^^
method < T > ( this : T , a ?: string ) : void {
// ^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
}
}JavaScript + espace sort :
class C extends Array {
// ^^^ ^^^^^^^^^^^^^^^^
field ;
// ^^^^^^^ ^^^^^^^^^
method ( a ) {
// ^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
}
}Essayez-le dans la cour de récréation.
Les avantages de cette bibliothèque sont :
./perf pour un micro-benchmarkSourceFile , car il peut être réutilisé - et la production de l'AST est la partie la plus longue.TypeScript )Toutes les syntaxes TypeScript ne sont pas prises en charge (voir syntaxe non prise en charge). Il n’y a pas non plus de déclassement ; le JavaScript est conservé tel quel.
npm install ts-blank-space export default function tsBlankSpace ( ts : string , onError ?: ( node ) => void ) : string ; import tsBlankSpace from "ts-blank-space" ;
console . log ( tsBlankSpace ( `let x: string;` ) ) ;
// "let x ;" export function blankSourceFile ( ts : typescript . SourceFile , onError ?: ( node ) => void ) : string ; import ts from "typescript" ;
import { blankSourceFile } from "ts-blank-space" ;
const ast = ts . createSourceFile ( ... ) ;
console . log ( blankSourceFile ( ast ) ) ; ts-blank-space expose les hooks de chargeur de module Node.js requis pour utiliser ts-blank-space pour prétraiter *.ts importés avant d'être évalués.
# Install (one time):
$ npm install --save-dev ts-blank-space
# Example usage (Node.js >= v18.20):
$ node --import ts-blank-space/register ./path/to/your/file.ts En plus du chargement des fichiers *.ts , un résolveur d'importation est également enregistré qui détecte les importations *.js ayant échoué et tente à nouveau l'importation en remplaçant l'extension par .ts . Cela permet aux chemins d'importation de choisir .ts ou .js en fonction des autres facteurs que le projet devra peut-être prendre en compte, tels que le regroupement et la distribution des packages.
Le chargeur suppose que tous les fichiers .ts sont des ESM.
Étant donné que tout le code JavaScript de la sortie se trouve sur la même ligne, colonne et décalage d'octets que la source d'origine, aucune information de mappage n'est perdue lors de la transformation.
Il existe deux cas, décrits ici, où il fait plus que remplacer la syntaxe TypeScript par un espace vide.
Pour se prémunir contre les problèmes ASI dans la sortie, ts-blank-space ajoutera ; à la fin des instructions de type uniquement, et lors de la suppression d'une annotation de type de début, cela pourrait introduire un risque ASI.
statementWithNoSemiColon
type Erased = true
( "not calling above statement" )devient :
statementWithNoSemiColon
;
( "not calling above statement" ) ; class C {
field = 1 /* no ; */
public [ "computed field not accessing above" ] = 2
}devient :
class C {
field = 1 /* no ; */
; [ "computed field not accessing above" ] = 2
} Si les annotations de type autour des paramètres d'une fonction fléchée introduisent une nouvelle ligne, alors seul leur remplacement par un espace vide peut être incorrect. Par conséquent, en plus de supprimer l’annotation de type, le ( ou ) entourant les paramètres de fonction peut également être déplacé.
let f = ( a : string , b : string ) : Array <
string
> => [ a , b ] ;devient :
let f = ( a , b
) => [ a , b ] ; async avec des arguments de type multiligne : let f = async <
T
> ( v : T ) => { } ;devient :
let f = async (
v ) => { } ; Certaines parties de TypeScript ne sont pas prises en charge car elles ne peuvent pas être effacées sur place en raison de la sémantique d'exécution. Voir unsupported_syntax.md.
Lorsqu'une syntaxe non prise en charge est rencontrée, ts-blank-space appellera le rappel facultatif onError et continuera. Des exemples peuvent être vus dans errors.test.ts .
tsconfig.json {
// Because JS syntax is emitted as-is
"target" : "esnext" ,
// Because class fields are preserved as written which corresponds
// to 'define' semantics in the ECMAScript specification
"useDefineForClassFields" : true ,
// Because imports and exports are preserved as written, only removing the
// parts which are explicitly annotated with the `type` keyword
"verbatimModuleSyntax" : true ,
} L'entrée .tsx générera une sortie .jsx . Les parties JSX ne sont pas transformées, mais conservées dans la sortie.
Par défaut, ts-blank-space analysera le fichier en supposant .ts . Si le fichier d'origine contient la syntaxe JSX, l'analyse doit être effectuée manuellement. Il existe un exemple TSX dans valid.test.ts .
import ts from "typescript" ;
import { blankSourceFile } from "ts-blank-space" ;
...
const tsxSource = ts . createSourceFile ( "input.tsx" , tsxInput , ts . ScriptTarget . ESNext , false , ts . ScriptKind . TSX ) ;
const jsxOutput = blankSourceFile ( tsxSource , onError ) ; TypeScript peut ajouter un export {}; si tous import et export ont été supprimés (car ils étaient import/export type ).
Étant donné que ts-blank-space supprime uniquement le code, cela n'est pas effectué. Pour forcer la sortie à toujours avoir un marqueur syntaxique ESM, vous pouvez ajouter manuellement "export {};" ;
Nous ❤️ contributions.
Avez-vous eu une bonne expérience avec ce projet ? Pourquoi ne pas partager un peu d'amour et contribuer au code, ou simplement nous faire part de tout problème que vous avez rencontré ?
Nous acceptons les rapports de problèmes ici ; assurez-vous de choisir le modèle de problème approprié à votre problème, afin que nous puissions être sûrs que vous fournissez les informations nécessaires.
Avant d'envoyer une Pull Request, assurez-vous de lire nos directives de contribution.
Veuillez lire le fichier LICENCE.
Ce projet a adopté un code de conduite. Si vous avez des préoccupations concernant le Code ou le comportement que vous avez constaté dans le projet, veuillez nous contacter à [email protected].
Veuillez vous référer à la politique de sécurité du projet.
