[BUG] Issue with Inline Defined Types

[tsteckenborn]

Is there an existing issue for this?

• I have searched the existing issues

Nature of Your Project

TypeScript

Current Behavior

Given an inline defined type, such as:

context: {
title: String;
content: String;
};

Using it within QL based on it's types, it's typed as:

context?: QLExtensions_<{title?: string | null; content?: string | null }>  | undefined

Leading to implied usage as:

[...]?.context?.content

Yet that leads to a tried access on a column named CONTENT.

Correct usage here would be:

[...]?.context_content

This works, but yields a type error.

Expected Behavior

Return a correct type for usage within QL also for inline defined types.

Steps To Reproduce

No response

Environment

- **OS**: Mac OS
- **Node**: v20.10.0
- **npm**: 10.2.3
- **cds-typer**: 0.12.0
- **cds**: 7.4.1

Repository Containing a Minimal Reproducible Example

No response

Anything else?

No response

[stockbal]

Hi @tsteckenborn,

did you pass the option --inlineDeclarations flat to the CLI? The default value for inline declarations is structured.

Structured produces a type like:

...
    context?: {
    title?: string | null,
    content?: string | null,
  } | null;
...

whereas flat produces:

...
    context_title?: string | null
    context_content?: string | null
...

P.S. You can also set this option in the VS Code settings

"cds.typeGenerator.command": "node \"${typerBinary}\" \"${targetFile}\" --outputDirectory \"${outputDirectory}\" --inlineDeclarations flat"

@daogrady what is the reasoning behind structured being the default? I don't see an option in CAP to store such an inline property as a single JSON object, like it is done with array of.

[daogrady]

Hi Ludwig,

thanks for weighing in on this matter!

what is the reasoning behind structured being the default?

That is a good question. I can not find any notes on the reasoning behind this. Looking at it today, I also believe that flat should be the default. I am a bit reluctant to change it now, as that would be a large breaking change and those are a bit harder to convey in the 0.y.z setup we are currently operating in.

Best,
Daniel

[stockbal]

Hi Daniel,

I thought at version 0.x.y you can basically do anything. Nothing is stable and the public API could be changed at any time. Sure, a lot of projects are probably using it right now, but I guess there is a reason you still keep at 0.x.y.

Best regards,
Ludwig

[daogrady]

Hi Ludwig,

yes, that is correct. 🙂
Still, it has led to confusion in the past, so I am trying to introduce breaking changes sparingly, if possible.

Best,
Daniel