[WIP] Add SwaggerConfig.outputBasename (needs tests) #589
Conversation
OpenApi 3.0 allows to no specify a scheme/host in the server URL part, in which case the scheme/host of the location where the document is served from should then be used by follup consumers. Until now if nothing special was specified always localhost:3000 was taken as default. To not break backwards compatability only enable relative locations when explicitly specifying "null" as host. This should most likely be changed with a new major breaking version. Fixes: lukeautry#540
* add ability to handle streams returned from controller * add test case for streamed buffer * reuse BufferType for Streamable results * improve stream ducktyping in express template
…tions Allow relative locations for OpenApi server URLs
Add unknown type (2.x)
Fix OpenAPI3 QueryArrays
> inside your own code base (i.e. it does **not** live in `./node_modules`) This seems like there's a word missing, though I'm new to the project so I _could_ be missing something.
Add a missing "not" in the docs:
|
@edbrannin I’m not at my desk so I can’t find the tests for you but if I recall properly there is an integration test folder that actually calls the tsoa CLI functions. That’s where you would want to change the config and then write an assertion that the file was created with the expected file name. |
Markdown will now render the two lines as separate
README: minor Markdown improvement
|
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
|
(While there are CLI-based integration tests, none of them actually look at the output yet. I'm going to have a look now and see if any of them actually generate output, then copy that one and change the output path.) |
|
After staring at the lack of CLI-oriented integration tests for a minute, I've extracted |
| import 'mocha'; | ||
| import { getSwaggerOutputPath, SwaggerConfig } from '../../../../src/module/generate-swagger-spec'; | ||
|
|
||
| const fakeSwaggerConfig = ({ outputDirectory, yaml, outputBasename, ...more }: { outputDirectory: string; yaml?: boolean; outputBasename?: string }) => { |
There was a problem hiding this comment.
There is a getDefaultOptions method you can reuse here.
Co-Authored-By: Wolfgang Hobmaier <wolfgang.hobmaier@sensoring.de>
Co-Authored-By: Wolfgang Hobmaier <wolfgang.hobmaier@sensoring.de>
Co-Authored-By: Wolfgang Hobmaier <wolfgang.hobmaier@sensoring.de>
|
I tried pulling from 3.x, but got a number of unrelated conflicts. I imagine I might be better off rebasing? |
Yes, I believe that'll be easier. Start from a fresh master and maybe cherry-pick your commits on top. |
|
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
All Submissions:
Closing issues
closes #360
If this is a new feature submission:
Potential Problems With The Approach
SwaggerConfig.outputBasename?is right next tooutputDirectory, but that violates a potential "All optional settings are below all required settings" that might be going on here. Should I move it down?Test plan
WIP: There aren't tests yet. I haven't been able to find any unit tests for this function, and I'd appreciate some guidance.
It looks like they might belong in
tests/unit/swagger/config.spec.ts.I don't see any tests referencing
fsWriteFileorfsReadFile-- would you prefer I actually write/read the swagger config or try to mock outfsWriteFile()? If mock, can you point me at another place where you're mocking?