Sometimes the most valuable guide is a working example. Lord knows, there are so many docs out there that keep prattling on and on instead of showing me the code.

99% of the working examples I encounter in JS config don't work by the time I get to them.

a working example that you don't understand and just copy over and over again into new projects.

This eventually turns into an incantation and magic. It's how crap gets built up and poor decisions get propagated.

> a working example that you don't understand and just copy over and over again into new projects.

Once you have a working example, you can go through it line by line and figure out what it is doing.

Honestly, I've always preferred to have somebody's example plus the reference documentation.

Learning not only what it does but where it's documented - and having to go look for myself to do so - fixes it in my memory a lot better.

I have a years old set of npm/etc. configs in a project I noodle on occasionally, and when I re-open them to look I remember exactly what they do -because- I started from a boilerplate and then went and learned how all of it works.

That doesn't mean an explanation wouldn't still be helpful for a bunch of people who aren't me, but honestly having the tsconfig commented like that is more than sufficient for -me- to be happy.

Which the author would be kind to do and post with the example.

You're right, but what guide is easier than "Just add the following files and run npm run dev. You'll be good to go!".

I'm personally against that belief as it doesn't really teach anything. Just adds a list of bootstrapping that you don't understand.

I find that almost all devs have a layer at which they don't understand what is going on. Everything we do is built on the shoulders of giants, as evidenced by how little we think about the 0s and 1s that are the actual end result of our work.

So I don't see a problem with any dev having a line of non-understanding as they work. Some peoples lines are lower than others, but we all work that way. So it is all good.

Absolutely, but don't call it a guide. When it's not.

> how little we think about the 0s and 1s that are the actual end result of our work.

but that doesn't mean you don't understand it.

You can get away with not thinking about it - for example, the error correction algorithms and protocols in tcp, or memory access - and that's because the designers of those layers have thought hard and long about how to keep it from leaking.

For js ecosystem, the designers (?) didn't think much at all. It is hobbled together rather haphazardly over time. Leading to the mess today.

There's only so much spoon-feeding that can be done. We already have so much information at our fingertips.

If people just want to copy+paste it then mark a jira issue as complete, that's up to them.

However, for those of us who want to understand - sometimes it's better to see a working example and pick at it.