Fix path generation

[HiiiiD]

Changes

What does this PR change? Link to any related issue(s).

Currently, if a url like https://api-test.<website>/docs/json is passed, then the regex creates a file with the https:// prefix before it, and so it doesn't work. It creates a file like https://api-test.<website>.ts

How to Review

How can a reviewer review your changes? What should be kept in mind for this review?

Checklist

• Unit tests updated
• README updated
• examples/ directory updated (if applicable)

[drwpow]

Thank you for adding! Could you add a test for this? I do think you are fixing an issue here but I’m not sure in what scenario this is encountered. A test would help.

[HiiiiD]

Can't add a test to verify that what I'm doing is right but the issue is that here there's a regex to rename the file
The fact is that if you put https://<domain>/docs.json, then it returns a URL resolved with https that clearly doesn't work

[HiiiiD]

BTW I've tried a couple more combinations and I've figured out that I should update the regex I've done because it doesn't cover all the cases

[HiiiiD]

I've removed the previous regex replace that I've added
Now https://<domain>.com/* with --output <dir>/ translates to <dir>/<domain>.ts while before, it the last part contained a . created a path like <dir>/<domain>/<before-dot>/*.ts

[drwpow]

Ohh the https is in the filename itself. I see. I think this is testable! It just may involve possibly mocking fetch as well as fs.writeFileSync for the test.

[HiiiiD]

I think that testing this PR may require #990 due to the fact that Pascal case headers don't seem to work

[drwpow]

Got it. Merged #990!

[HiiiiD]

I think I've an issue with tests
It shows 24 failed tests, with the codebase on the main branch

[drwpow]

So sorry about the delay to merging this one. It slipped through the cracks. Thank you for your patience!

[drwpow]

@all-contributors please add @HiiiiD for code, bug

[allcontributors]

@drwpow

I've put up a pull request to add @HiiiiD! 🎉

[dgee2]

Thanks this is really useful for me (hoping to get http yaml files on our build server rather than storing them in source control for a project)

It does look like this has broken another scenario where I'm loading all yaml files from a directory. The following gives an error on both windows and our linux build server. I assume it is because of the wildcard search for the input files.

openapi-typescript ./open-api/*.yaml --output ./src/generated/open-api

Output from yarn:

$ openapi-typescript ./open-api/*.yaml --output ./src/generated/open-api
✨ openapi-typescript 6.2.2
node:fs:599
  handleErrorFromBinding(ctx);
  ^

Error: EISDIR: illegal operation on a directory, open 'C:\git\cyclone_accountmanagementui\cyclone_accountmanagementui\src\generated\open-api'
    at Object.openSync (node:fs:599:3)
    at Object.writeFileSync (node:fs:2221:35)
    at generateSchema (file:///C:/git/cyclone_accountmanagementui/cyclone_accountmanagementui/node_modules/openapi-typescript/bin/cli.js:122:8)
    at async file:///C:/git/cyclone_accountmanagementui/cyclone_accountmanagementui/node_modules/openapi-typescript/bin/cli.js:195:7
    at async Promise.all (index 0)
    at async main (file:///C:/git/cyclone_accountmanagementui/cyclone_accountmanagementui/node_modules/openapi-typescript/bin/cli.js:185:3) {
  errno: -4068,
  syscall: 'open',
  code: 'EISDIR',
  path: 'C:\\git\\cyclone_accountmanagementui\\cyclone_accountmanagementui\\src\\generated\\open-api'
}

Node.js v18.7.0
error Command failed with exit code 1.

[HiiiiD]

Gotcha @dgee2, it's because we're using writeFileSync
I personally didn't think of a directory, and didn't see any test on it, so I skipped this case
I'd suggest creating an issue and I'll take a look as soon as I can💪