fix(cli): improve openapi code generation for naming and typing

[raymondfeng]

Fixing issues to generate code from OpenAPI specs from https://www.berlin-group.org/psd2-access-to-bank-accounts. Here is the swagger doc.

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[raymondfeng]

berlin-group-swagger-2.yaml.txt

[jannyHou]

What does the declaration here mean?

[raymondfeng]

For example, for a type alias export type IDType = string:

• name: `IDType
• declaration: string

[b-admike]

Wondering if the signature can be usOffice: USAddress; or usOffice: Address here instead.

[raymondfeng]

Good question. I'll check.

[raymondfeng]

It should be fixed. I have to recursively resolve $ref for some models.

[bajtos]

Have you considered the following, to avoid duplication of getJSType?

: getJSType( 
  // The item type can be an alias such as `export type ID = string`
  propertyType.itemType.declaration ||
  // The item type can be `string`
  propertyType.itemType.name
)

[bajtos]

👍

[bajtos]

I am wondering - why are we including name in the property metadata? Isn't the decorator inferring the property name automatically? I believe the property name specified in the metadata must match the property name in TypeScript source, otherwise things will break at runtime.

IMO, we should exclude name from the generated property metadata.

Feel free to leave such changes out of scope of this pull request.

[raymondfeng]

Some of the property names such as last-name have to be set in the @property decoration. I didn't bother to test if the original name is the same as the TS property.

[bajtos]

Some of the property names such as last-name have to be set in the @property decoration. I didn't bother to test if the original name is the same as the TS property.

So how is this going to work in practice? Let's say the OpenAPI schema describes a property called last-name. This means the clients will be sending request body payload like {"last-name": "Bajtos"}.

At runtime, this will create object {'last-name': 'Bajtos'}.

To allow TypeScript code to access this data, the TypeScript property must be called last-name too. If it's changed e.g. to lastName, then

• TypeScript code won't be able to access the real property value.
• Values set from TypeScript (e.g. data.lastName = 'Feng') will be ignored by model's toJSON function, thus they won't be persisted in the database and serialized to HTTP responses.

Some of the property names such as last-name have to be set in the @Property decoration.

Are you saying that our code in incorrectly inferring model property name from the TypeScript/JavaScript property name passed by TypeScript to @property? I.e. that the following won't work?

@model()
class MyModel extends Entity {
  @property()
  'last-name': string;
}
``

[raymondfeng]

The following code should work:

@model()
class MyModel extends Entity {
  @property()
  'last-name': string;
}

But we prefer to support the following:

@model({name: 'my-model'})
class MyModel extends Entity {
  @property({name: 'last-name'})
  lastName: string;
}

Mapping between JS/TS and JSON should be allowed. But @loopback/repository does not support that yet.

[raymondfeng]

See #2743