Integrate the TypeScript codegen into the new common codegen

[lecoqlibre]

Historically, each version of the connector had its own codegen repo. But we decided to merge them in one place to ease the deployment and maintenance.

The TypeScript version still has its own repo and should be incorporated into the new https://github.com/datafoodconsortium/connector-codegen.

This will require to create a new folder in the src and rewrite the codegen using Acceleo queries. The tests should also be generated.

The PHP version could be a great source of inspiration.

Maybe the time to support auto-imports?

[jgaehring]

Making my way through this. I just pushed the rough scaffolding to my fork. For now it generates nothing but an empty TypeScript class and/or interface for the main objects in the model, plus the core static files, but I'm not seeing any errors yet, at least not for the TS stuff. There is some noise about PHP generator, but that was already popping up before I began.

I'm thinking about a few options for when it comes time to bundle this up for release, perhaps related to datafoodconsortium/connector-codegen#16 like you mention above. Specifically I'm wondering about how to structure the output/library modules and whether to take into consideration whether consumers may wish to "tree shake" the parts of the model that might not be required by the downstream application, so they're excluded from the final bundle (especially if that's for the browser). That's probably more of a consideration for the tsc compiler and could be tweaked in the tsconfig.json either by us or the downstream consumer, but it also begs whether its worth using some automation to generate plain EcmaScript/JavaScript modules that would be run as-is in Node or a browser (with the supported versions we choose to target specified for each). Those may be stretch goals, and perhaps warrant opening separately in Discussions, but thought I'd just note it here before I forgot.

[lecoqlibre]

Nice @jgaehring it sounds like a good start. Yes, the PHP produce some errors you could ignore. +1 for thinking about bundle things, we could handle this later but it's good to have it written somewhere (maybe it could be better to track this in an issue).

Like I said few days ago during our call with @RaggedStaff I added a JS vocabulary generator. In fact, I've made it some time ago so I had just to push it. This way you will be able to replace lines like the following in constructors (ex: Catalog.ts):

const type: string = "https://github.com/datafoodconsortium/ontology/releases/latest/download/DFC_BusinessOntology.owl#Catalog";

with:

import { DFC } from '@datafoodconsortium/vocab-business';

const type: string = DFC.Catalog; // or even better, remove this "type" variable and replace all occurrences with DFC.Catalog.

Also all the lines regarding semantic properties could be changed.

This will decouple the connector from the vocabulary so users would be able to use the vocabulary alone, it will reduce the size of the connector, and we could update the vocabulary without updating the connector.

The vocab has been released on NPM (@datafoodconsortium/vocab-business).

I guess we should do the same with our taxonomies @RaggedStaff. We could set up GitHub actions to automatically generate these libraries.

[jgaehring]

The vocab has been released on NPM (@datafoodconsortium/vocab-business).

Oh great, makes much more sense now that I see it. Thanks!

[lecoqlibre]

@jgaehring If it's OK for you you could commit and push your local commits on your fork as you go so I could look at it sometimes.

I think we could also factorize the code of getters, setters, adder and removers methods which are present in all classes.

Indeed, the code is very similar from one class to another.

We could write an abstract class like SemanticObjectDfc (in the static folder) which will extend SemanticObject and make the end classes extending the SemanticObjectDfc class instead of the SemanticObject one.

The code of the previous methods should be moved into this new class and should be called by sub classes.

[lecoqlibre]

@jgaehring In fact I was mistaking when I said to replace the type like with DFC.Catalog in constructors (comment https://github.com/datafoodconsortium/connector-typescript/issues/4#issuecomment-1936337109).

Indeed, the UML model now uses prefixed mapping. So the code generator will receive things like dfc-b:Address. See this line for an example.

I guess the expansion of the prefix is managed by the Semantizer library. I will have to look at it for the TypeScript version.

• Semantizer PHP
• Semantizer TypeScript

[jgaehring]

Indeed, the UML model now uses prefixed mapping. So the code generator will receive things like dfc-b:Address. See this line for an example.

Ah, yes, I saw that and wondered. I went poking around and found the context.ts mapping in the datafoodconsortium/connector-codegen-typescript repo but didn't see it being referenced anywhere in the static files or generated output. The vocab-business-typescript library looks far more complete and easier to use. From what I can grok of the PHP semantizer, it's using EasyRdf and setting it as a $resource, which I also noticed was an optional parameter for most of the PHP connector's constructors. So while I've been trying to maintain parity with the PHP connector, that is one place I omitted the feature, because I didn't see anything equivalent in the connector-codegen-typescript repo either.

In general that's been my method, pretty much how you suggested: start with the PHP model templates and cross check with TypeScript templates and generated code. So I'm picking up stuff like the use of async calls for TypeScript, making sure that's retained in the new templates, even though I don't think the PHP has any mechanism like that.

Apologies for the late response. My schedule's been a little erratic, but I pushed some more changes to my branch earlier this afternoon, and hopefully should have a few more to push before tomorrow.