Closed joprice closed 1 month ago
You can use --out-file
to write to a file.
I am not sure what is the best practices for logging, I looked several for Logging libraries both in F# and JavaScript world, to be honest I never understood how to use they correctly. They all seems to make things complex for no good reason.
I'm using pino for js, but it's overkill for a cli. The basic approach I usually use in things that meant to have pipe-able output is to print data on stdout and metadata on stderr. That way, if something fails, the file you're redirecting to winds up being empty and the errors are visible (along with more verbose debug or informational logs -app name, version header, progress messages etc), instead of having a file that contains errors and having to cat it to see them or having tooling choke on invalid output. In this case it could be as simple as switching printfn
s to eprintfn
s. When using a higher level log framework, you could then configure it to route by log level to stdout or stderr.
Thanks for fixing this one! It's working nicely. Very convenient for my workflow checking quickly checking the output for different .d.ts
files.
Happy to help where I can :)
And TBH I am not a fan of the --out-file
but I think I added it in prevision of multiple files support for Glutinum. As multi file will probably not support piping to stdout. But I am not here yet and we will see at that moment how things goes.
When running the cli, the output includes the generated fsharp code along with some other informational messages. To support easily piping the output to a file without requiring ad-hoc cleanup, they could be sent to stderr instead.
The common ones are
Generating binding file for....
andSuccess!
, but perhaps in some branches there are others printed to stdout. I think there is also a strayprintfn
that was left from debugging that prints the file multiple times on some runs:https://github.com/glutinum-org/cli/blob/23ef41fc7e03bd45e11da60a6ff1bae9a206c535/src/Glutinum.Converter/Reader/Utils.fs#L154