ferdikoomen
Preserve modules and declarations in build & distribution
First of all, excellent library, it was a pleasure to work with the parsed meta data from parse(). Thanks!
For the services output, I wanted to generate only functions (instead of classes with methods). This is efficient in terms of tree-shakeability of the resulting functions (and hooks). We previously had a solution in which we post-process the output files of this library, but by using parse() and the returned meta data directly, we can use our own templates to generate services and hooks very efficiently.
I've read #427. Still, I'd love to propose this PR that results in a non-bundled dist folder and the TS declaration files.
As it stands, I believe it's basically negligible in terms of additional costs of maintenance or performance. I've ran all tests and also used this on my own (fairly large) project without issues.
Obviously when people use internal modules from this package things may break when file names and/or structure would change (but personally I'd have no issues with this). As a follow-up you might want to consider exposing (only) the parse function(s), allowing to use custom templates with the results. I think this may result in folks using this library in new and interesting ways, without sacrificing the original spirit and intent.
Thanks for considering this, feel free to close it as you see fit. Then I'll likely fork and publish this version if you don't mind.
When npm install-ing this from my fork I found the *.d.ts source files were not included in the rollup output. Only the generated ones from the declaration: true setting were included.
The last commit adds them. In a rather unconventional way, as I couldn't figure out a way to do this properly using rollup, a plugin, and/or TypeScript configuration. Maybe you or someone would know of a better way to do this.
So I figured out source DTS files are never transferred by tsc. They can be copied manually, or renamed from *.d.ts to .ts to include them.
As I've progressed in using only the parser and further cleaned up my clone, I've created https://github.com/webpro/parse-openapi. I've mentioned your name and repository, and added a (MIT) license.
One thing I did in my repo is to start using https://github.com/kogosoftwarellc/open-api. This seems like a solid option so you would not need to maintain them yourself.
I'd be happy to discuss further, but feel free to close this PR. I'm grateful for the inspiration that led to the other repo.
@webpro I'm not against exposing separate files, however the API for each method is not what i consider "public" only the main method and CLI commands are supported. I know that you will understand that, but this might not be true for all others. The original ticket was about properly splitting the codebase into section, i love that idea, but right now i have no time to make a design (and do the work) for this. But i'm happy to have a look at a 'cheap' solution like you are proposing, with some warning in the README files
