@dthyresson warned me (very gently) for creating a new discussion in the existing Redwood Logging - Ideas?, so with proper apologies, I am reposting it here.
Once discussing the concept of logging as a tool to detect otherwise difficult-to-find bugs, did anyone think about logging as a means to automate the application development? The idea is simple: the current development consists of the following steps (as documented in the tutorial doc)
- Run
yarn create redwood-app
- Run several generators
- Edit manually some of the generated files
…
My problem with this approach is in its unidirectional characteristics (from beginning to end). So, if I mess something up after step 21 dependent on the size of the problem, I have to start from scratch (unless I am so experienced to address the problem directly). If however, all these steps are sufficiently described in the log that is being created as I type, I could simply grab my Log player tool and run the whole development work up to the point where the bug was introduced.
This could significantly improve the tool development process, make it more reliable and enable the library of such logs (scripts) as a replacement for application skeletons and more. Given infinite resources, one could argue that such Log player could be perceived as RAD tool (I probably should not even mention this as it looks difficult to make without creating a complete mess, difficult to unravel)
I don’t think saying that I “warned you” is a fair view of my comment:
@adriatic this sounds like a separate concept from this current topic which is a Logging Library for RedwoodJS.
If so, could you create a new topic so one might discuss this there?
I suggested that your discussion would better be served as a new topic rather than in a thread regarding a logging library because it’s a different topic ;).
That said when you say:
I meant to use the logging “script” as a side effect of the current app development process, not to “raise” the programming level to the scripting process. However, if done right, it could be used to create the application “beginnings” way further than yarn create redwood-app , in addition to the customer problem reports as the best method of reproducing the problem.
or
if I mess something up after step 21 dependent on the size of the problem, I have to start from scratch (unless I am so experienced to address the problem directly). If however, all these steps are sufficiently described in the log that is being created as I type, I could simply grab my Log player tool and run the whole development work up to the point where the bug was introduced.
In pure practical terms, what are you suggesting?
- Logging the output of yarn rw commands to a file (
described in the log that is being created as I type)?
- Some sort of VCR-like recording and replay of your yarn rw commands that you can record, rollback or replay?
Is there in existing tool or example you can point to to help demonstrate the idea? What current DX problems might it solve?
To be clear, I’m not discounting your idea – I’m simply trying to understand your idea for “another use of logging” better in less abstract terms so others can discuss and contribute.
If you are right in saying that, I would have to apologize even more - and I am doing it now. English not being my first language, I may get a bit of reprieve; If you see me walking to a hole in the sidewalk reading the newspaper and you warn me that I am about to fall in, I would not think of such warning as an inappropriate gesture 
(note, that I equate this situation where I am about to fall in the hole with my stepping in your post with some nearly irrelevant content)
I am suggesting both as the first is the prerequisite for the second.
I would think that LogRocket (if I understand it correctly) is a good example. It offers help in debugging as well as helping reproducibility of the problem. Here is the quote from their website https://logrocket.com/
Stop guessing why bugs happen
LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster.
I should add that I as a developer using Redwood to create my apps, I can use LogRocket to my heart’s content, however such use of a non-integrated tool would be far inferior to the solution based on my proposal.
Finally, my choice of the subject for this thread may need a more marketing based approach
Also - if you are talking about logging RedwoodJS CLI commands then that might instead be considered “telemetry” ie the data companies and tools collect on usage and to gather error reports with their SDKs etc.
For example, Prisma collects info on invoking its commands:
The term telemetry refers to the collection of certain usage data to help improve the quality of a piece of software. Prisma 2 uses telemetry in two contexts:
* collecting usage data
* submitting error reports
This page describes the overall telemetry approach for Prisma 2, what kind of data is collected and how to opt-out of data collection.
Thank you for this reference, @dthyresson! Microsoft collects similar data (from Windows OS) for similar reasons. While RedwoodJS could be interested in Telemetry, my initial scope is narrower:
RedwoodJS users (app developers) use the data for debugging(their code is instrumented) and RewoodJS may decide to offer the instrumented version of the framework (this is basically the idea being discussed in Redwood Logging - Ideas?.
Until I get a few opinions on this idea, I will not expand my article with more detail - being a fresh novice, I do not want to pollute this space without some expressions of interest