Not working on TS 5.0

[samchon]

When run ttsc command, below error occurs:

D:\github\samchon\typia\node_modules\ttypescript\lib\patchCreateProgram.js:84
    tsm.createProgram = createProgram;
                      ^

TypeError: Cannot set property createProgram of #<Object> which has only a getter
    at patchCreateProgram (D:\github\samchon\typia\node_modules\ttypescript\lib\patchCreateProgram.js:84:23)
    at loadTypeScript (D:\github\samchon\typia\node_modules\ttypescript\lib\loadTypescript.js:21:56) 
    at Object.<anonymous> (D:\github\samchon\typia\node_modules\ttypescript\lib\tsc.js:8:46)
    at Module._compile (node:internal/modules/cjs/loader:1226:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1280:10)
    at Module.load (node:internal/modules/cjs/loader:1089:32)
    at Module._load (node:internal/modules/cjs/loader:930:12)
    at Module.require (node:internal/modules/cjs/loader:1113:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (D:\github\samchon\typia\node_modules\ttypescript\bin\tsc:2:1)

[szatanjl]

Don't know if it is related but I was looking through the code and I find the commit f37f095 suspicious.

It adds check if tsc version is >= 4.9 (I believe that was the intent), but does so incorrectly major >= 4 && minor >= 9 @ tsc.ts

[samchon]

You're right, I did a mistake on the version specification.

However, TS 5.0 breaks ttypescript too, even when fixing the version checking error.

The error comes from tsm.createProgram became a readonly proeprty.

---

import ts from "typescript";

console.log(ts.createProgram);
ts.createProgram = function () {} as any;

TypeError: Cannot set property createProgram of #<Object> which has only a getter

[samchon]

This problem is based on TS 5.0 has changed target build option from es5 to es2018.

Such break change invalidates key logic of ttypescript.

I wrote an issue about that in TypeScript repo, but I think ttypescript needs to ready for that - @cevek

microsoft/TypeScript#52826

[jakebailey]

@samchon This problem has nothing to do with the target being changed. TypeScript is now itself authored in modules, which do not allow at-runtime modification of exports, as opposed to previous versions which used TS namespaces, which are just objects and could be modified (though any modification like that would be very, very fragile as there's no guarantee the exported property would be used internally).

[damiangreen]

is there a workaround to this?

[nonara]

Here's a quick update for everyone - the changes in v5 required a new approach for a few reasons, but we have it solved and are about to release a new version of ts-patch.

We've opted to add drop-in replacement support for ttypescript which has had lagging maintenance support for a while now.

What this means is, you can install ts-patch and simply use tspc, the same as you would use ttsc. It will be on-the-fly, in memory modification, although it's notably faster due to our caching mechanism.

We're nearly finished, so you can expect this soon.

[sunrabbit123]

@damiangreen
If you don't have time to migrate, enter

> yarn remove ttypescript
> yarn add -D ttsc

If so, your project will work just fine as is.
Unless you're only using ts-node and cache features.

If you have enough time to migrate, we recommend using ts-patch.

[nonara]

For clarity, the whole point of "drop-in-support" means you don't have to "migrate". You simply install and use tspc instead of ttsc.

Creating another fork is not good imo.

@sunrabbit123 last I saw, your solution lacks a critical piece, which will strip transformers of the full functionality that many will need, so you should be aware of that.

There is more to this than simply patching createProgram, for tsc.js

[sunrabbit123]

If so, it's simply a library that only works for now, so the
Isn't that a good thing for you, who only want one library?

I don't have a big picture, I just developed and deployed what I needed for the moment.
@nonara

[sunrabbit123]

In case you're wondering, the
I'm not interested in extending the functionality.
I'm just concerned with typescript version compatibility.

[nonara]

In general, I believe not forking is generally the ideal path, if it can be done, but there are certainly times which call for it. I just tend to take the long view in that forks (or any new project) should be planned carefully and done with the intention of maintaining it for the long term, for as long as people rely on it.

With that said, it's OSS, so it definitely isn't for me to tell others what to do. I just wanted to voice my thoughts on it and also to let you know of the potential issues many will face with the approach in your PR. It's an issue we've faced and had to solve for over the years with both tts and tsp.

That being said, I know people are anxious, so if your solution works for their particular plugins without any issue, I think it's great that they have something to use in the mean time!

[sunrabbit123]

Numerous forks clutter the ecosystem, but they also make it mature.

Competition is necessary for better products,
As a company owner, I'm sure you know the benefits of having competition.

Of course, from the user's point of view, as you say, it's inconvenient and unsettling when the product, the interface, is not fixed.
That's what you're concerned about.

That's why I'm talking about it.
I'm not interested in extending features.

So any transpiler that works with TTSC will work with TSP.
Of course, it may not be the opposite.