Typewriter 2.0 release date?

[Gambero81]

@frhagn there are some news about v2.0 release?

Thanks

[agustinbcu01]

any progress?

[GitHubish]

The project really seems to be abandoned. We have been using Typewriter in my team for years. This was a significant advance over T4. But unfortunately Typewriter gradually died out, no longer following the evolution of Typescript. As a result, the technology hardly responds to the need without having to write complex and quickly unreadable code.

I really hope that the project will catch its breath...

[agustinbcu01]

Any progress with 2.0

[SamuelKupferschmid]

@frhagn is there a way to support you to make v2.0 a reality? This Project already works great for many existing solutions and a lot of ideas for 2.0 make totally sense to me.

[dev-buildableworks]

@frhagn Our company would contribute funding to this project. Typewriter is essential.

[s4m0r4m4]

@frhagn's last commit was April 20, 2019 (simple update to support VS2019), and it doesn't look like there's been significant amounts of work since late 2017. There are 106 open issues and 5 open PRs at the time of this comment.

Issue #290 (from @atotalnoob) also has some good discussion on whether this is in active development. Frhagn's last comment on that thread was on Dec 31, 2018, where he said he was still working on a v2.0 and wanted to drop something on github at some unknown time in the future.

Known forks with potentially useful changes:

• https://github.com/ReactiveThings/Typewriter/tree/cli (19 commits ahead, is a .NET CLI port of typewriter)
• https://avilv.github.io/TypewriterX/ (ability to split one C# file into multiple typescript files, but not an open-source project?)
• https://github.com/werddomain/Typewriter (made one change: https://github.com/frhagn/Typewriter/compare/master...werddomain:master)

Between @dev-buildableworks, @atotalnoob, and @ReactiveThings, perhaps we can get an "official" Typewriter 2.0 fork repo and start getting people to switch over? I have nothing against fraghn and have immense appreciation for all the work he has done, but the repo just does not seem to be supported anymore.

[grey280]

I'd be interested in helping with this "official" 2.0 fork, as well.

I've looked at the ReactiveThings CLI variant a very little bit. If memory services, @valantonini did a lot of the work there, tagging them so they'll see this discussion.

[dev-buildableworks]

We were discussing it last week, and the benefit of typewriter generating on the fly is actually a liability. It's slows down visual studio too much. We'd rather have a button on the toolbar to push to generate typescript than it being automatic. When working with native script (for example), it conflicts with webpack that is watching the file changes too, and freezes visual studio, turns out most of us have learned to kick-off typewriter by doing quick file saves.

@s4m0r4m4 we would be up for a rewrite as a compile time option. A node script would be nicer than a c# one, wouldn't it? We can then add toolbar buttons to launch the script.

[tomgruszowski]

Wanted to mention @AdaskoTheBeAsT as well, he seems to push minor updates as well (haven't tried his fork).

https://github.com/AdaskoTheBeAsT/Typewriter/tree/feature/upgrade

He's also got another TypeScript Generator https://github.com/AdaskoTheBeAsT/TypeScriptGenerator

[AdaskoTheBeAsT]

@tomgruszowski thanks - indeed Typewriter is really cool addon and I poked a little with keeping it updated on my fork - also started to check if SourceGenerator would be an option here - by general I wanted to achieve similar results to things which were possible in Typewriter for angular - https://github.com/AdaskoTheBeAsT/NetCoreTypewriterRecipes/blob/master/src/AngularWebApiSample/ClientApp/src/api/models/_AutogeneratedModels.tst https://github.com/AdaskoTheBeAsT/NetCoreTypewriterRecipes/blob/master/src/AngularWebApiSample/ClientApp/src/api/services/_AutogeneratedServices.tst

[SamuelKupferschmid]

Cool to see some comments popping up here. I really appreciate the work done so far by @frhagn . I am willing to contribute as well. I think we all see the power of the current syntax as well as the lack of support for recent c# features.

I will start reading into the current implementation as well as the PoC given by @AdaskoTheBeAsT in the next days.

[s4m0r4m4]

@dev-buildableworks - although the generation on the fly is nice for some situations (projects with significant amounts of C#), I can see where it could also be a problem for situations like the one you described. Perhaps the best path forward is to put the translation functionality into a CLI that is independent of VS, and then wrap it in a VS extension that has a setting for whether code generation should be on-the-fly or button-triggered. I feel like that would cover a lot of the use cases that I've seen people asking for.

As far as a node script vs. a C# one, I don't have a strong opinion there. I think the most important things are to maintain is the format of the .tst files and to keep the behavior as similar to the existing Typewriter as possible. It does look like @ReactiveThings did port the functionality into a .NET Core CLI (https://github.com/ReactiveThings/Typewriter/tree/cli). I'm not sure how the release of .NET 5 will affect that, but it seems like a potentially good starting point.

[grey280]

As a Mac-and-Windows user, I'd definitely prefer that approach - much easier to have a .NET Core CLI that I can use cross-platform than it is to develop a plugin for both Visual Studio and Visual Studio for Mac.

[tomgruszowski]

RE: node script, would this mean a standalone C# API would now potentially have node_modules to execute this code generation? and npm install as part of setup? What about the potential cleanup associated with this? It doesn't feel right, unless there is already a well written version in JS that addresses this problem, I don't see this technical mix as a positive. If we're already working in .NET, we should probably leverage this (reflection comes to mind) and keep dependencies to a minimum; of course this may be contradicted with the various versions of VS/.NET as well.

[s4m0r4m4]

Good points, I think it depends on what development environment you assume for the user (whether they're coming at if from a node/JavaScript setup or a C#/.NET setup), but I agree that a .NET CLI script seems to fit most users better.

I think at this point somebody needs to step up and decide to host v2 on github. I'd be happy to help support that repo and point people towards it to get the community and supporters moving on, but I don't have the skills to write that code from scratch myself. I think the repo I mentioned above by ReactiveThings is a good place to start, and we could probably just wrap it into a Visual Studio extension (maybe a VS code extension too?).

[gregveres]

I think that it would be great to have something that allows .Net Core developers to migrate to developing on the Mac instead of windows.

I would also like to see some suggestions on what the resulting TS code looks like. I have been creating interfaces that are in a single namespace but that is so TS 1.6ish. :) But I just don't know how else to approach the problem because interfaces build on and include other interfaces. I couldn't figure out a way to have one generated file know the name of another generated file to include in order to pull in the needed definition of the used interface.

[atotalnoob]

I'm open to helping anyone with new development of typewriter.

I'm just very busy, so I can't take lead.

If one assigns me issues with clear requirements and tag me, I will complete them, no problem.

I really wish that this project gets taken up and uses dotnet global tools.

StrawberryShake is an example of what I would expect from typewriter 2.0.

Additionally, I believe we must support generation from other projects. At my current company, we can't benefit from typewriter because we use a microservice approach, so we have many projects, including a common "library" with all of our models. Since this is outside of the front-end project,,typewriter does not work

[AdaskoTheBeAsT]

@SamuelKupferschmid sorry was recently ultra busy with life - some life combo stopped me @gregveres you need to craft typewriter script to be able to include references from other files - you can find sample here https://github.com/AdaskoTheBeAsT/NetCoreTypewriterRecipes/blob/master/src/AngularWebApiSample/ClientApp/src/api/models/_AutogeneratedModels.tst

[gregveres]

@AdaskoTheBeAsT Thank you for the reference. I will check it out. I am about to rewrite our UI in Vue so now is a perfect time to change how I am importing the back end models.

One other thing I am struggling with as I move to vue is that most a bunch of tools don't seem to like typescript const enums. Personally I think they are fantastic and have converted all my c# enums to TS const enums. It gives me some type safety in the front end with the efficiency of just using numbers everywhere.

I see that you use Angular. What do you do for enums from the back end?

[AdaskoTheBeAsT]

@gregveres you should definitelly look at at tst file ;) I just generate them also - i have two options - as numeric one and as string one I have additional attributes on enums and I also generate labels for enums just from c# https://github.com/AdaskoTheBeAsT/NetCoreTypewriterRecipes/blob/master/src/AngularWebApiSample/ClientApp/src/api/models/FirstSet.ts https://github.com/AdaskoTheBeAsT/NetCoreTypewriterRecipes/blob/master/src/AngularWebApiSample/ClientApp/src/api/models/SecondSet.ts

it is generated from https://github.com/AdaskoTheBeAsT/NetCoreTypewriterRecipes/blob/master/src/AngularWebApiSample/Models/FirstSet.cs and https://github.com/AdaskoTheBeAsT/NetCoreTypewriterRecipes/blob/master/src/AngularWebApiSample/Models/SecondSet.cs

[gregveres]

Yea I use an attribute I named [ExportToTypescript] that will export my enums and classes. I will take a look at how you generate them. Thank you so much for sharing the recipes.

[AdaskoTheBeAsT]

You welcome :)

[gregveres]

@AdaskoTheBeAsT Hi, I am just now getting a chance to look at this. The one thing I notice is that in your examples, you always have one class per file with the file named after the class. This definitely makes things easier to figure out how to import the interface when you need it.

However, in my code, we group things by functionality. So we might have a file that handles updating the user's profile and that file might be called UserProfileOperations.cs. Then in that file, we define some small classes, or enums, say for the user's preferences for something.

const enum UserEmailSharingOptions { ... }

So to get this enum included in TS, I would have to:

import { UserEmailSharingOptions } from '@api/UserProfileOperations'

Did you ever run into that situation? And if so, were you ever able to solve it?

[AdaskoTheBeAsT]

Hi @gregveres,

as I always follow one class per file rule I didn't encounter such necessity. Keeping multiple classes enums in one file generally complicates algorithm for imports and I would try to avoid it by using simple convention.