ts blank space
v0.4.3
Um removedor de tipo JavaScript pequeno, rápido e puro que usa o analisador TypeScript oficial.
TypeScript entra:
class C < T > extends Array < T > implements I {
// ^^^ ^^^^^^^^^^^^^^^^
private field ! : string ;
// ^^^^^^^ ^^^^^^^^^
method < T > ( this : T , a ?: string ) : void {
// ^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
}
}JavaScript + espaço sai:
class C extends Array {
// ^^^ ^^^^^^^^^^^^^^^^
field ;
// ^^^^^^^ ^^^^^^^^^
method ( a ) {
// ^^^ ^^^^^^^^ ^^^^^^^^^ ^^^^^^
}
}Experimente no playground.
Os benefícios desta biblioteca são:
./perf para um micro-benchmarkSourceFile , porque ele pode ser reutilizado – e produzir o AST é a parte mais demorada.TypeScript )Nem toda sintaxe TypeScript é suportada (consulte sintaxe não suportada). Também não há rebaixamento; o JavaScript é preservado como está.
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 expõe os ganchos do carregador de módulo Node.js necessários para usar ts-blank-space para pré-processar *.ts que são importados antes de serem avaliados.
# 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 Além de carregar arquivos *.ts , um resolvedor de importação também é registrado, que captura importações *.js com falha e tenta novamente a importação, substituindo a extensão por .ts . Isso permite que os caminhos de importação escolham .ts ou .js dependendo de quais outros fatores o projeto pode precisar levar em consideração, como agrupamento e distribuição de pacotes.
O carregador assume que todos os arquivos .ts são ESM.
Como todo o JavaScript na saída está localizado na mesma linha, coluna e deslocamento de byte da fonte original, nenhuma informação de mapeamento é perdida durante a transformação.
Existem dois casos, descritos aqui, em que faz mais do que substituir a sintaxe TypeScript por espaço em branco.
Para se proteger contra problemas de ASI na saída, ts-blank-space adicionará ; ao final das instruções somente de tipo e, ao remover uma anotação de tipo inicial, pode introduzir um perigo de ASI.
statementWithNoSemiColon
type Erased = true
( "not calling above statement" )torna-se:
statementWithNoSemiColon
;
( "not calling above statement" ) ; class C {
field = 1 /* no ; */
public [ "computed field not accessing above" ] = 2
}torna-se:
class C {
field = 1 /* no ; */
; [ "computed field not accessing above" ] = 2
} Se as anotações de tipo em torno dos parâmetros de uma função de seta introduzirem uma nova linha, apenas substituí-las por espaço em branco poderá ser incorreto. Portanto, além de remover a anotação de tipo, o ( ou ) ao redor dos parâmetros da função também pode ser movido.
let f = ( a : string , b : string ) : Array <
string
> => [ a , b ] ;torna-se:
let f = ( a , b
) => [ a , b ] ; async com argumentos do tipo multilinha: let f = async <
T
> ( v : T ) => { } ;torna-se:
let f = async (
v ) => { } ; Algumas partes do TypeScript não são suportadas porque não podem ser apagadas devido à semântica de tempo de execução. Consulte unsupported_syntax.md.
Quando uma sintaxe não suportada for encontrada, ts-blank-space chamará o retorno de chamada opcional onError e continuará. Exemplos podem ser vistos em 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 ,
} A entrada .tsx gerará a saída .jsx . As partes JSX não são transformadas, mas preservadas na saída.
Por padrão, ts-blank-space analisará o arquivo assumindo .ts . Se o arquivo original contiver sintaxe JSX, a análise deverá ser feita manualmente. Há um exemplo de TSX em 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 pode adicionar um export {}; se todos import se export s foram removidos (porque eram import/export type ).
Como ts-blank-space remove apenas código, isso não é executado. Para forçar a saída a sempre ter um marcador sintático ESM, você pode anexar manualmente "export {};" ;
Nós ❤️ contribuições.
Você teve uma boa experiência com este projeto? Por que não compartilhar um pouco de amor e contribuir com código, ou apenas nos contar sobre quaisquer problemas que você teve com ele?
Aceitamos relatórios de problemas aqui; certifique-se de escolher o modelo de problema adequado para o seu problema, para que possamos ter certeza de que você está fornecendo as informações necessárias.
Antes de enviar uma solicitação pull, certifique-se de ler nossas Diretrizes de contribuição.
Por favor, leia o arquivo LICENSE.
Este projeto adotou um Código de Conduta. Se você tiver alguma dúvida sobre o Código ou sobre o comportamento vivenciado no projeto, entre em contato conosco pelo e-mail [email protected].
Consulte a Política de Segurança do projeto.
