EE interface instead of `warn` function? about normalize-package-data HOT 5 CLOSED

The alternative (i.e. for the code I have now) would be:

var parse = require("read-package-data")
parse(data, function (warning) {
  doSomething(warning)
})

I'd say that's shorter, less pretentious.
Parser is a bit of a misnomer. First of all it doesn't really parse. It's a transformation of a tree structure. Second, the word parse makes me expect the input argument would remain unaffected.

An advantage of your approach would be the ability to configure the parser once. That could be convenient in some circumstances, although right now I have a hard time imagining a real use case. Or actually I do. Current read-package-json could configure this object once, when it gets loaded. But it would almost be just as easy to let that module pass its internal logging function every time. It would be truly useful if someone would actually want to pass a (configured) parser around, but I'm not sure that would happen soon.

The other interesting thing of the event interface is the possibility for more kind of events than just warnings (without if statements in the callback). And of course multiple listeners.

I guess I could also implement both, i.e. export a parse function with a "parser" function as property. (the word "parse" is nice and short, for now)

Given a sensible use case, I'd write it in a heartbeat, but right now we're coming from a situation where this code was used closely tied to just a simple logger, so I'm a little bit cautious.

from normalize-package-data.

Yeah, I guess "parser" would be a bad name. Parsers should take string input and do stuff with it. The API you have here is probably fine. Maybe the default "warn" function could do a console.error?

from normalize-package-data.

Or just a noop. I lean towards noop, because then you have a super clean way to normalize data, if you're code is not able to do something meaningful with the errors. Say, when doing it inside npm-www (how this got started after all). I think there you just want to disregard any warnings. You just want as good as data as possible.

from normalize-package-data.

Good point. No warn method is probably best just silencing the warnings.

from normalize-package-data.

I realized earlier that "warning" may not be the best name to use. I think that generally speaking, the normalizer is commenting on the stuff it sees. The caller of the function could turn these "comments" into warnings if it makes sense in that specific case.

Say for npm-www, there's nothing scary about having tons of "invalid" (but non-throwing) package data around. It's just how it is.
When using the parser during development and/or publishing of a package, the caller would better warn the user about it. (during publishing, perhaps abort, but explain why - because of the warnings).

Personally, I think that would be a cool win already: Having code that (for example with a watch script) validates package.json for you in real-time.

from normalize-package-data.