Skip to content
This repository has been archived by the owner on Jul 9, 2018. It is now read-only.

peerDependencies deprecation #18

Open
clux opened this issue Apr 17, 2014 · 1 comment
Open

peerDependencies deprecation #18

clux opened this issue Apr 17, 2014 · 1 comment

Comments

@clux
Copy link
Owner

clux commented Apr 17, 2014

If peerDependencies get deprecated then we will need a better way to enforce same usage. The current solution basically requires the module author to ensure logule can be required. Try catch in each module or something. This is ugly.

Dependency injection on the other hand is ultimately as ugly for something as simple as a logger, so require + straight up use should really work..

Maybe the better way is to move towards a pattern where every module that wants to log expose a readable log stream that logule can consume.

Need to think about this some more.

@clux
Copy link
Owner Author

clux commented Apr 2, 2015

Having thought about this a while, I think it's too late to change this really. People can manage their logule dependencies in their own app if they want total control, but it is ultimately a bit annoying - and makes publising modules with logule harder (but published apps have no problems).

Personally, I may move to a more event-emitter based logging style from libraries, and use a bunch of log subscribers in my app - then this is no longer an issue. I made two basically empty modules doing this yesterday: smell and sulfur. Following in those footsteps feels easier - logule feels a bit over-architected to me at the moment for the following reasons:

  • file logging feature is simplistic

It's a simple, no-log-rotating, version that you should almost never leave on a long lived server. Ideally you just want to write to stdout, and have a service like pm2 manage your logs and log rotation.

  • formatting configuration is huge

Look at sulfur - you could replicate the entire style in a one line function. The timestamp craziness is almost depressing. You don't want this in your library.

  • peerDependencies makes your module less desirable

You almost always should just expose an EventEmitter from your library to keep it reusable.

  • peerDependencies not guaranteed to work

Thus it may always require some work in your tree to get logule's best feature: branch based log filtration.

Maybe I should make a logule subscribe for smell, or make a small standalone subscriber like sulfur that preserves the style of logule perhaps. Comments welcome if people care.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant