Un eliminador de tipos de JavaScript pequeño, rápido y puro que utiliza el analizador oficial de TypeScript.
TypeScript entra:
class C < T > extends Array < T > implements I {
// ^^^ ^^^^^^^^^^^^^^^^
private field ! : string ;
// ^^^^^^^ ^^^^^^^^^
method < T > ( this : T , a ?: string ) : void {
// ^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
}
}
Sale JavaScript + espacio:
class C extends Array {
// ^^^ ^^^^^^^^^^^^^^^^
field ;
// ^^^^^^^ ^^^^^^^^^
method ( a ) {
// ^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
}
}
Pruébelo en el patio de recreo.
Los beneficios de esta biblioteca son:
./perf
para obtener un micro-benchmarkSourceFile
, porque se puede reutilizar y producir el AST es la parte que consume más tiempo.TypeScript
)No toda la sintaxis de TypeScript es compatible (consulte sintaxis no compatible). Tampoco hay descenso de nivel; el JavaScript se conserva tal cual.
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
expone los ganchos del cargador de módulos Node.js necesarios para usar ts-blank-space
para preprocesar *.ts
que se importan antes de evaluarlos.
# 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
Además de cargar archivos *.ts
, también se registra un solucionador de importaciones que detecta importaciones *.js
fallidas y vuelve a intentar la importación reemplazando la extensión con .ts
. Esto permite que las rutas de importación elijan .ts
o .js
dependiendo de qué otros factores el proyecto deba tener en cuenta, como la agrupación y la distribución de paquetes.
El cargador supone que todos los archivos .ts
son ESM.
Debido a que todo el JavaScript en la salida está ubicado en la misma línea, columna y desplazamiento de bytes que la fuente original, no se pierde información de mapeo durante la transformación.
Hay dos casos, descritos aquí, en los que hace más que reemplazar la sintaxis de TypeScript con espacios en blanco.
Para protegerse contra problemas de ASI en la salida, ts-blank-space
agregará ;
hasta el final de las declaraciones de solo tipo, y cuando la eliminación de una anotación de tipo inicial podría introducir un peligro de ASI.
statementWithNoSemiColon
type Erased = true
( "not calling above statement" )
se convierte en:
statementWithNoSemiColon
;
( "not calling above statement" ) ;
class C {
field = 1 /* no ; */
public [ "computed field not accessing above" ] = 2
}
se convierte en:
class C {
field = 1 /* no ; */
; [ "computed field not accessing above" ] = 2
}
Si las anotaciones de tipo alrededor de los parámetros de una función de flecha introducen una nueva línea, entonces solo reemplazarlas con espacios en blanco puede ser incorrecto. Por lo tanto, además de eliminar la anotación de tipo, también se puede mover el (
o )
que rodea los parámetros de la función.
let f = ( a : string , b : string ) : Array <
string
> => [ a , b ] ;
se convierte en:
let f = ( a , b
) => [ a , b ] ;
async
con argumentos de tipo multilínea: let f = async <
T
> ( v : T ) => { } ;
se convierte en:
let f = async (
v ) => { } ;
Algunas partes de TypeScript no son compatibles porque no se pueden borrar en su lugar debido a que tienen semántica de tiempo de ejecución. Consulte unsupported_syntax.md.
Cuando se encuentra una sintaxis no compatible, ts-blank-space
llamará a la devolución de llamada opcional onError
y continuará. Se pueden ver ejemplos en 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 ,
}
La entrada .tsx
generará una salida .jsx
. Las partes JSX no se transforman, sino que se conservan en la salida.
De forma predeterminada, ts-blank-space
analizará el archivo asumiendo .ts
. Si el archivo original contiene sintaxis JSX, entonces el análisis debe realizarse manualmente. Hay un ejemplo de TSX en 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 puede agregar una export {};
si se eliminaron todas import
y export
(porque eran import/export type
).
Debido a que ts-blank-space
solo elimina código, esto no se realiza. Para forzar que la salida tenga siempre un marcador sintáctico ESM, puede agregar manualmente "export {};"
;
Nosotros ❤️ contribuciones.
¿Has tenido una buena experiencia con este proyecto? ¿Por qué no compartir un poco de amor y contribuir con el código, o simplemente contarnos cualquier problema que haya tenido con él?
Damos la bienvenida a los informes de ediciones aquí; asegúrese de elegir la plantilla de problema adecuada para su problema, de modo que podamos estar seguros de que está proporcionando la información necesaria.
Antes de enviar una solicitud de extracción, asegúrese de leer nuestras Pautas de contribución.
Lea el archivo de LICENCIA.
Este proyecto ha adoptado un Código de Conducta. Si tiene alguna inquietud sobre el Código o el comportamiento que haya experimentado en el proyecto, contáctenos en [email protected].
Consulte la Política de seguridad del proyecto.