TypeScript is becoming more and more ubiquitous and I think that is a good thing. 4 years ago, I argued that valid JS is not valid TS, but TS has matured a lot since then.
I would also go as far, to teach new programmers TypeScript from the start, rather than JavaScript.
JavaScript involves a lot of guesswork or try and error if you know nothing.
How do you explain to someone that some DOM event _will_ have a special property they should consume? REPL-based programming is still a thing for trying out that kind of things and it helps greatly to learn about the return values (or types) of functions. But once you know what an event listener is, what you can attach it to, you really want to rely on signatures right off your editor. Code is documentation too, and TypeScript enables code to be self-documenting in a way. If implemented correctly, I don't have to try out functions but simply know what they do by looking at their signature, which means a great productivity boost to me.
We still have a large gap between the developers that sprinkle in JavaScript as additive for some special effects on regular websites or full-blown web apps that have devops baked into them. Think PHP in ~2010. There are still people using FTP to deploy their websites, so an extra build step comes with a huge up-front cost you probably don't want to pay.
In these places, usage of TypeScript is kind of a gray zone, as you cannot rely on completely automatic deployment.
Which is why I am looking forward for the type annotation proposal: https://github.com/tc39/proposal-type-annotations
Good alternative to useState for an array of objects:
useListState - https://mantine.dev/hooks/use-list-state/
I remember mui also had one, but can't find it right now.
Reading your source code and capabilities of your logger made me realize what I expect and want from a logging library.
1. configurable log levels (convention is fine, but some apps require more fine grained control)
2. filterable log output - pino is doing really good here, you get JSON with level and message and can filter with jmes path. pretty printing is handled by another process that gets piped in the json lines (pino-pretty)
3. error handling logging - format and display errors with stack traces, maybe output 1-2 lines from the source code that caused it. That would be a game changer for nodejs applications.
4. Transports - easy way to hook into logging to fork off into another file, online service etc. Using a stream or EventEmitter.
**Other things to note:**
your logging class is stateful, I wouldn't want to set "no color" when another file is accessing the same logger. This should be an option when creating the logger or overwritable with the function (although I would prefer the first option)
It makes it even harder to manage that, when I can't create new logger instances on my own, as you just export `new Logger()` already. That means I can't use a prefix for different modules because `require('inklog')` will always give me the same logger instance.
Your methods are repeating the same logic over and over. Put them into a shared function.
Nice idea, however:
* allow to utilize environment variables in 12 factor apps (dotenv additionally)
* writing configuration becomes necessary once you allow users to change details
* provide an async way to retrieve the config file (classes will not allow that in a constructor)
* cache the config file until it is changed
* watch for changes of the config file and notify consumers (observers)
I am still looking for a flexible configuration format/library, so I believe there is still a huge market for that to be explored. For my demands it was hard to find something really useful so far, so I had to bake my own alternatives.
In more strict environments (like when programming with FP paradigms), you maybe even want to configure not only data but also behavior. To express that in pure JSON files is probably not worth it, and we need to keep dependencies and raw data configuration separate.
Guess who is butthurt to get a taste of their own medicine.. lol
How bad of you to not have any spam counter measures.
I hope the spam of whoever will be as helpful as what you expected from us to do from your spam.
Reading your source code and capabilities of your logger made me realize what I expect and want from a logging library. 1. configurable log levels (convention is fine, but some apps require more fine grained control) 2. filterable log output - pino is doing really good here, you get JSON with level and message and can filter with jmes path. pretty printing is handled by another process that gets piped in the json lines (pino-pretty) 3. error handling logging - format and display errors with stack traces, maybe output 1-2 lines from the source code that caused it. That would be a game changer for nodejs applications. 4. Transports - easy way to hook into logging to fork off into another file, online service etc. Using a stream or EventEmitter. **Other things to note:** your logging class is stateful, I wouldn't want to set "no color" when another file is accessing the same logger. This should be an option when creating the logger or overwritable with the function (although I would prefer the first option) It makes it even harder to manage that, when I can't create new logger instances on my own, as you just export `new Logger()` already. That means I can't use a prefix for different modules because `require('inklog')` will always give me the same logger instance. Your methods are repeating the same logic over and over. Put them into a shared function.