Migrate JDL to typescript

[mshima]

Overview of the feature request

JDL is quite complicated to understand and missing a few features. We should migrate it to typescript to make it simpler and may receive more contributions.

Motivation for or Use Case

Improve developer experience.

Related issues or PR

• [ ] Checking this box is mandatory (this is just to show you read everything)

[mshima]

What do you think @deepu105 @MathieuAA?

[MathieuAA]

+1 The whole project should benefit from using TS

[MathieuAA]

However, TS won't be the holy grail. It can make things a bit more understandable but we need conventions for the whole project (for instance interfaces, what actually qualifies as an internal breaking change, etc.). This is a good solution, but it won't be enough

[mshima]

However, TS won't be the holy grail. It can make things a bit more understandable but we need conventions for the whole project (for instance interfaces, what actually qualifies as an internal breaking change, etc.). This is a good solution, but it won't be enough

Sure, can you take this ticket?

[emilpaw]

@mshima Which part of JDL are you talking about exactly? There are many files related to JDL. That would be probably too much to do at once.

I suggest to enable TS as a first step. Then smaller parts can be gradually migrated to TS.

[mshima]

@mshima Which part of JDL are you talking about exactly?

The entire jdl folder.

There are many files related to JDL. That would be probably too much to do at once.

Sure can be split in several PRs or even issues, but the issue is to track the entire jdl support (folder). It's decoupled from the generators, IMO it's the best place to start typescript migration. And then we should evaluate if we should migrate everything else and replace ESM to typescript at https://github.com/jhipster/generator-jhipster/issues/19113

[pascalgrimaud]

@mshima : I'm removing the bounty, following this https://www.jhipster.tech/bug-bounties/#how-bug-bounties-are-created

And I'm putting back the bounty, as it's totally deserved. So plz, ping Daniel, Deepu, Julien or me, if you think a ticket needs one :-)

[MathieuAA]

If you all are serious about using TS instead of JS, then we need a clear strategy that:

• won't impact daily contributions
• will move us toward a goal of having a good enough TS vs JS coverage
• will actually prevent us from making mistakes that can be avoided by using TS

Thus, we have to measure those:

• flag and count any issue where TS is impacting contributions,
• measure the coverage and check it's going up steadily (LoC),
• same as the first point, we need to flag and count

The last point is to check whether TS is a good fit.

[pedrolucasoliva]

I like so much prisma's schemes. Maybe it can be a source of inspiration. https://www.prisma.io/docs/concepts/components/prisma-schema

[mraible]

We should check with the author of the JHipster JDL plugin for IDEA. I'd hate for their hard work to be impacted by this change.

https://plugins.jetbrains.com/plugin/19697-jhipster-jdl

[emilpaw]

Sure can be split in several PRs or even issues, but the issue is to track the entire jdl support (folder).

I already worked on migrating some files to TS in https://github.com/jhipster/generator-jhipster/pull/19558. So far it seems the code migration itself will be rather straightforward. But I think it might be better to just first configure the compilation and build of the project before working on migrating the code. I started to work on the configuration here: https://github.com/jhipster/generator-jhipster/pull/19559

I like so much prisma's schemes. Maybe it can be a source of inspiration.

I am not sure in what regards this might be an inspiration. The ticket is about migrating the code of JDL from JavaScript to TypeScript. The JDL itself should not change.

@MathieuAA I agree that we need to plan a migration strategy for the rest of the project, but I think this could be discussed after this ticket in a new issue. WDYT?

@mraible The build output will be JavaScript, so it should not be a problem.

[mshima]

@emilpaw I’ve managed to use mocha + @esbuild-kit/esm-loader. It works pretty well, I couldn’t see any performance drop. Have problems when updating inline snapshots, but IMO is worth it.

[emilpaw]

@mshima I created a draft PR for what I've done so far: #19856 Interestingly the pipeline succeeds while locally some of the tests fail.

In the last few days, I had no time to work on this but I am continuing to work on it again now.

[MathieuAA]

A good way to migrate the project, JDL included, could be to:

• simply add the TS dependency in the project and some setup so that there's no change at all
• module by module, file by file (PR by PR) change the extension to use TS and use TS concepts

This makes the migration process way easier and the review way easier too