Maybe we can get a simple cli?

[vanyauhalin]

I thought it might be useful. I often have to use large tools like esbuild to simply transform TypeScript to JavaScript without actually doing anything complicated. I would gladly give them up in favor of this library. On the one hand, I think it is an interesting development, but I would not be inclined to extend the current API. I think it is complete, and that is great. If I were to solve this problem, I would create a separate ts-blank package that would include a very simple set of CLI-specific features, as well as a loader for Node.js. Yes, the current solution already contains a loader, but I would conceptually separate it. For now, these are just thoughts; I wanted to share them and learn yours.

Usage: ts-blank [options]

Options:
  --tsconfig    Path to the tsconfig.json

We can use the typescript --showConfig and access files, compilerOptions.rootDir, compilerOptions.outDir fields. The compilerOptions.allowImportingTsExtensions could be usefull too.

[acutmore]

Hi @vanyauhalin!

I would create a separate ts-blank package

Yeah, I completely agree. One goal of ts-blank-space is to remain focused on having one responsibility allowing other packages to wrap it and add extra functionality such as a CLI or bundler integrations.

[davidrhoderick]

What's the status on this @vanyauhalin? I was going to switch from tsc because it started giving me headaches on a legacy JS project where we are introducing TS and I think this would be a better alternative but introducing webpack to use ts-blank-space is not a good solution. A CLI like tsc would make this really killer...

[vanyauhalin]

@davidrhoderick Hi, David. I have a prototype of this CLI. It works, but it is not published yet. I have switched to other projects that do not use JavaScript at all, so the work has paused a bit. The fact that you wrote to me indicates that I am not the only one who needs this kind of CLI. I am glad you did. I will not promise anything, but I will try to get back to work as soon as possible.

[KillyMXI]

I need one solution that can act as a loader both for my tests and for easily runnable examples.
Currently, seems like I have to switch to ts-blank-space for my tests but unable to get rid of tsimp because of code examples.
One package with loader and CLI would be most convenient for me.

[vanyauhalin]

TLDR

Repo: vanyauhalin/tsb
Package: @vanyauhalin/tsb

$ npm i --save-dev @vanyauhalin/tsb
# ...

$ npm exec tsb -h
Usage: tsb [tsc options and arguments]
See tsc --help for available options and arguments.

$ npm exec tsb -p tsconfig.build.json
# ...

Some Background

I started working on the CLI almost immediately after writing this issue.

I made an MVP during the first couple of days. At that point, I had a poor understanding of the TypeScript codebase — or rather, no understanding at all. I had no experience working with their API and no reason to delve into their code. Therefore, the MVP was implemented rather crudely: I read and parsed the tsconfig.json file using several functions from the public TypeScript API; took the list of files directly from the config; transformed them using ts-blank-space; and saved them to disk. Additionally, I experimented with writing transformers, for example, to transform .ts and .tsx imports back to .js and .jsx. There was no support for passing compiler options via arguments; everything was handled through the configuration file. It worked, but I had a strong feeling that I was doing something wrong — it functioned, but I do not like how it. The code was approximately three times longer than the released package, which was not pleasing. Consequently, I set the project aside and switched to another one that did not use JavaScript at all, so the work on the CLI was temporarily suspended.

The first wake-up call was a message from @davidrhoderick. Although I did not give up on the idea, I assumed that the pause might be long. This message cut me off, showing that this could be useful to others besides myself. However, things did not progress beyond feelings. The second wake-up call was a message from @KillyMXI. At that point, I decided it was time to resume work.

I restored the code and decided to start completely from scratch while building upon previous work. This stage differed from the first in that I began exploring the TypeScript codebase. I became interested in how tsc itself works. Oh my goodness, it is a thing. Within two days, the MVP was rewritten. The result looked better, and there were fewer doubts about the direction, but there was still no support for options via arguments, and some remnants from the earliest developments remained. The result looked better, and there were fewer doubts about the direction, but there was still no support for options via arguments, and some tails from the very first developments still remained. At that time, I began to consider keeping the CLI simple while making it behave as similarly as possible to tsc. This thought changed much, because until then, I had done everything manually and specifically. For example, when reading the configuration file, I extracted only certain options that I thought might be useful in the future; I independently converted the runtime config data into what users could see in the tsconfig.json file to support the showConfig option, and so forth. Much was accomplished, but continuing in this manner while trying to mimic tsc would have multiplied the potential logic several times. Doubts appeared.

The next day I woke up with a dirty thought — what if I use the internal API? In all my conscious practice, for me, using an API marked as internal had been taboo and was never discussed. If the author does not want us to use that part of their program, we should respect that. For tsb, the question became critical: either write extensive code to achieve a satisfactory result or completely surrender to the mercy of the TypeScript codebase. I chose the latter. Gradually, pieces of my code that could be replaced with internal functions began to be removed. Additional dependencies also disappeared because TypeScript is comprehensive. The task evolved into relatively straightforward reverse-engineering, where I needed to recreate a simplified version of the process from parsing arguments to running the compilation. I believe I have succeeded. While tsb was originally intended to be a small tool that merely used the tsconfig.json as its configuration file, it now aims to become a drop-in replacement for tsc where possible. Currently, tsb consists of 500 lines of code, of which 100 are mapping functions from TypeScript, with only two dependencies — ts-blank-space and TypeScript itself.

There are some downsides. At the moment, the loader is not written; there are no tests; not all configuration options are supported; and information about unsupported options does not show during execution. However, I believe it meets the basic requirements. I encourage you to try it.

Last point. The package was supposed to be called ts-blank, however, it turns out that such a package had already existed in npm history, so now it is tsb under my namespace.

$ cloc bin lib

       9 text files.
       9 unique files.
       0 files ignored.

github.com/AlDanial/cloc v 2.02  T=0.01 s (784.9 files/s, 66021.1 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
TypeScript                       8            115            139            495
JavaScript                       1              2              1              5
-------------------------------------------------------------------------------
SUM:                             9            117            140            500
-------------------------------------------------------------------------------

$ cloc lib/typescript.ts

       1 text file.
       1 unique file.
       0 files ignored.

github.com/AlDanial/cloc v 2.02  T=0.01 s (126.3 files/s, 27778.5 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
TypeScript                       1             26             91            103
-------------------------------------------------------------------------------

Some Pictures

I have attached a couple of pictures that demonstrate how the error messages will appear.

[KillyMXI]

This is very cool!

But maybe I should also clarify what was on my mind, because it is obvious in hindsight that there are different things to expect behind "cli".

Besides loader functionality, the other feature I need the tools (currently tsimp) for is running .ts files like .js files.
Examples:

"benchmark:js": "node ./benchmarks/benchmark.js",
"benchmark:ts": "tsimp ./benchmarks/benchmark.ts",
"example:calc": "tsimp ./examples/calc.ts",

tsimp converts the code to own cache folder and runs immediately, transparently for me.

This might become unnecessary with Node 22. But before Node 20 is out of LTS, I need something else.

[vanyauhalin]

Besides loader functionality, the other feature I need the tools (currently tsimp) for is running .ts files like .js files.

Sorry, but I do not see the difference. The command below should work for you, should not?

node --import ts-blank-space/register ./benchmarks/benchmark.ts

[KillyMXI]

Ok, I'm dumb and forgot about something.
So, the only difference is more tidy command.

[Snowflyt]

Just for reference, you can always use node -e "..." in your scripts to execute code directly from the CLI. For now, I‘ve simply copied and pasted the following stupid line into the build script in package.json:

node -e \"import path from 'node:path'; import fs from 'node:fs'; import tsBlankSpace from 'ts-blank-space'; fs.cpSync('src', 'dist', { recursive: true }); fs.readdirSync('dist', { recursive: true }).map((file) => path.join('dist', file)).filter((file) => file.endsWith('.ts') && !file.endsWith('.d.ts') && fs.statSync(file).isFile()).forEach((file) => { fs.writeFileSync(file.substring(0, file.lastIndexOf('.')) + '.js', tsBlankSpace(fs.readFileSync(file, 'utf-8'))); fs.rmSync(file); })\"

When expanded into multiline:

import fs from 'node:fs';
import path from 'node:path';
import tsBlankSpace from 'ts-blank-space';

fs.cpSync('src', 'dist', { recursive: true });

fs.readdirSync('dist', { recursive: true })
  .map((file) => path.join('dist', file))
  .filter((file) => file.endsWith('.ts') && !file.endsWith('.d.ts') && fs.statSync(file).isFile())
  .forEach((file) => {
    fs.writeFileSync(
      file.substring(0, file.lastIndexOf('.')) + '.js',
      tsBlankSpace(fs.readFileSync(file, 'utf-8')),
    );
    fs.rmSync(file);
  });

Alternatively, some may prefer to write a separate build.js file instead of including everything in package.json, which can be easier to maintain.

It might be a dumb solution, but it feels clean to me without adding much extra complexity to the build process. As a library author, I'm tired of relying on a myriad of build tools just to publish a straightforward package.