TypeError: Cannot read properties of undefined (reading 'slice')

[kubakl]

What are the steps to reproduce this issue?

1. Write a config for react-query as the client
2. Run orval command (v6.9.2

What happens?

A weird error appears, don't even know what's the issue
…

What were you expecting to happen?

Generate the models and API operations for all the enpoints
…

Any logs, error output, etc?

petstore - TypeError: Cannot read properties of undefined (reading 'slice')
…

Any other comments?

I saw there's already an issue which is really similar #494
…

What versions are you using?

Operating System: MacOS X (M1)
Package Version: v6.9.2
Browser Version: …

[anymaniax]

Hello @kubakl do you have an example for me?

[kubakl]

@anymaniax What type of example you want me to give you? The OpenAPI spec?

[anymaniax]

If you can yes

[kubakl]

Sorry for not answering, I assume it's a config issue, I copied it from the documentation but still it may be wrong:

module.exports = {
  petstore: {
    output: {
      mode: 'tags-split',
      target: 'src/petstore.ts',
      schemas: 'src/model',
      client: 'react-query',
      mock: true,
    },
    input: {
      target: '../schema/api-v1.yaml',
    },
  },
};

The schema doesn't have any issues because I also generate golang code using openapi-generator and it works just fine.

[anymaniax]

Hi @kubakl, I would need the yaml or an example that reproduce the error with the yaml

[lmossman]

@anymaniax I'm reviving this thread as I am running into the same issue with orval printing out

🛑  api - TypeError: Cannot read properties of undefined (reading 'slice')

I have created a repo with a simple example that can be used to reproduce this error: https://github.com/lmossman/orval-example

To reproduce the error, you can follow these steps:

1. git clone git@github.com:lmossman/orval-example.git
2. cd orval-example
3. npm install
4. npm run orval
   which will output the error above.

I believe this error happens when trying to reference an external json/yaml file in the OpenAPI spec, like I do on this line that I added to your petstore.yaml sample file:
https://github.com/lmossman/orval-example/blob/a8c46736987cf2ffd3fd3b7bf6f50048937000b4/src/petstore.yaml#L116-L117

I have confirmed that the openapi-generator validates my OpenAPI spec successfully, and is able to produce client code from it. So this issue seems to be specific to orval not being able to handle referencing external files.

Let me know if there is any other info that I can provide here! I'd love to get this fixed as we need to be able to reference external files in our production application that is using orval. Thanks!

[kubakl]

As @lmossman says, I also have the same structure in my OpenAPI definition, I split it across different files, paths, schemas, responses etc. This actually could be the problem.

[hbarrientosg]

As temporary solution you could generate your schema with openapi-cli and then use orval with the output.

openapi-cli bundle yourschema.yaml -o tmp/yourschema.json && orval --config orval.config.ts --clean

On your orval you should add the generated file.

...
    input: {
      target: resolve(__dirname, "./tmp/yourschema.json"),
    },
...

[lmossman]

@hbarrientosg nice suggestion, I will try that! Thanks

Of course it would be preferred if this was fixed natively in orval, though

[anymaniax]

Hello @lmossman, @hbarrientosg, @kubakl, I improved the parsing and everything should work as expected in the next release

[lmossman]

@anymaniax I have upgraded to version 6.11.0-alpha.5 of orval, and while I no longer get the TypeError posted above, the generated typescript still doesn't seem quite right.

For components that are pointing to external JSON schema files, the typescript file that orval generates still doesn't contain classes for the referenced JSON. It just adds a type onto the field which is the capitalized version of the field name, but doesn't actually define what that type is.

For example, in my orval-example repo that I created to demonstrate this behavior, I point to a breed.json JSON schema file here with a $ref: https://github.com/lmossman/orval-example/blob/ae07d4565f2851a86b211240e92259a5bfa1994d/src/petstore.yaml#L116-L117

But when I run npm run orval, the Petstore.ts file it generates just contains this interface definition for Pet, without ever defining the interface for Breed: https://github.com/lmossman/orval-example/blob/ae07d4565f2851a86b211240e92259a5bfa1994d/src/client/Petstore.ts#L29

So pointing to an external file results in broken typescript code generated from orval.

[anymaniax]

@lmossman can you try 6.11.0-alpha.6 and tell me if it's good for you now?

[lmossman]

@anymaniax it is a bit closer now, but I still have a couple of issues:

1. If the external JSON schema file is in some nested path, then orval uses two different names for the generated type.
   For example, here I am now pointing to a nested directory that contains the JSON schema, and this results in orval generating the Pet object with a breed field of type Breed, but it defines that type with the name PathToSchemaBreed
2. It seems that orval is only generating types for the top-level fields in the external JSON schema, whereas I need it to generate types for every field and every nested field in that JSON schema.
   For example, here I point to an external JSON schema file which contains a definitions block, containing JSON schema blocks that are pointed at with $ref in other parts of the file. This does produce an output file, but it only defines the top-level PathToSchemaBreedNested type, and doesn't define types for nested fields like Ancestry. Orval also prints out these warnings when I run orval on that file:

🍻 Start orval v6.11.0-alpha.6 - A swagger client generator for typescript
🎉 api - Your OpenAPI spec has been converted into ready to use orval!
⚠️  SyntaxError: Swagger schema validation failed.
  #/paths/~1pets/get/responses/200/content/application~1json/schema/items/properties/breed must NOT have additional properties
  #/paths/~1pets/get/responses/200/content/application~1json/schema/items/properties/breed must have required property '$ref'
  #/paths/~1pets/get/responses/200/content/application~1json/schema/items/properties/breed must match exactly one schema in oneOf
  #/paths/~1pets/get/responses/200/content/application~1json/schema/items must have required property '$ref'
  #/paths/~1pets/get/responses/200/content/application~1json/schema/items must match exactly one schema in oneOf
  #/paths/~1pets/get/responses/200/content/application~1json/schema must have required property '$ref'
  #/paths/~1pets/get/responses/200/content/application~1json/schema must match exactly one schema in oneOf
  #/paths/~1pets/get/responses/200 must have required property '$ref'
  #/paths/~1pets/get/responses/200 must match exactly one schema in oneOf
  #/paths/~1pets~1{petId}/get/responses/200/content/application~1json/schema/properties/breed must NOT have additional properties
  #/paths/~1pets~1{petId}/get/responses/200/content/application~1json/schema/properties/breed must have required property '$ref'
  #/paths/~1pets~1{petId}/get/responses/200/content/application~1json/schema/properties/breed must match exactly one schema in oneOf
  #/paths/~1pets~1{petId}/get/responses/200/content/application~1json/schema must have required property '$ref'
  #/paths/~1pets~1{petId}/get/responses/200/content/application~1json/schema must match exactly one schema in oneOf
  #/paths/~1pets~1{petId}/get/responses/200 must have required property '$ref'
  #/paths/~1pets~1{petId}/get/responses/200 must match exactly one schema in oneOf
  #/components/schemas/Pet/properties/breed must NOT have additional properties
  #/components/schemas/Pet/properties/breed must have required property '$ref'
  #/components/schemas/Pet/properties/breed must match exactly one schema in oneOf
  #/components/schemas/Pet must have required property '$ref'
  #/components/schemas/Pet must match exactly one schema in oneOf
  #/components/schemas/Pets/items/properties/breed must NOT have additional properties
  #/components/schemas/Pets/items/properties/breed must have required property '$ref'
  #/components/schemas/Pets/items/properties/breed must match exactly one schema in oneOf
  #/components/schemas/Pets/items must have required property '$ref'
  #/components/schemas/Pets/items must match exactly one schema in oneOf
  #/components/schemas/Pets must have required property '$ref'
  #/components/schemas/Pets must match exactly one schema in oneOf

🎉 apiNestedJson - Your OpenAPI spec has been converted into ready to use orval!

If orval can correctly produce an output file for that petstore_nested_json.yaml spec which contains properly-named types for Breed, Ancestry, and OriginLocation, that would be perfect! Thanks

[anymaniax]

@lmossman I fixed the two issues but still have a little problem with the relative path. Will try to fix it asap to be able to release a new alpha with it

[anymaniax]

In the end, I found a solution quicker than I thought so you can test with 6.11.0-alpha.7

[lmossman]

@anymaniax I tried this out and it seems to have fixed most of the issues I was seeing. However, when I tried this out in the actual project I am using orval for, I still ran into a case where a typescript type did not properly get generated for a definition in the JSON file.

I have updated my example here to demonstrate this issue. Notice that if you run npm run orval on that repo's current master, the Petstore.ts file that it generates does not contain a type definition for JsonSchema or SimpleRetriever.

I think this may be an issue with allOf in the JSON schema - having this field in an object seems to cause orval to not generate a type for it.

[anymaniax]

@lmossman can you try with orval@6.11.0-alpha.9

[lmossman]

@anymaniax thanks for the quick response! This is looking really close, but I found one more issue: it seems that two duplicate typescript types with the same name are being generated in the case that there are two fields with almost the same name (only a _ prefix differentiates them).

I've updated my repo here with an example of this: the DeclarativeStream definition in my JSON schema has a schema_loader and a _schema_loader field each with the same anyOf value, and this causes orval to generate two identical DeclarativeStreamSchemaLoader types, which is not allowed since it is a duplicate identifier.

[kubakl]

Now it works for me with no problems, thx very much!

[lmossman]

@anymaniax is it looking like the issue I described above is a straightforward fix? I think this is the last issue that is blocking me from using orval in our production app so I'm really looking forward it being resolved!

[anymaniax]

@lmossman you can try with 6.11.0-alpha.10 should be fixed

[lmossman]

@anymaniax that seems to have fixed it! Thank you for the quick response. I believe all of the issues called out in this thread have been resolved in the latest version, so this issue can be closed out

[anymaniax]

@lmossman cool don’t hesitate if you have other issues

[lmossman]

FYI @anymaniax I discovered another problem, so I opened an issue here: #726