natural: log4js causing issues with client-side usage
I’m trying to use natural on the client side and I’m getting errors on (Webpack) compilation like the following:
Error in ./~/log4js/lib/appenders/clustered.js
Module not found: 'cluster' in /Users/liadrian/Dev/naive-bayes/node_modules/log4js/lib/appenders
@ ./~/log4js/lib/appenders/clustered.js 3:14-32
Error in ./~/log4js/lib/appenders/gelf.js
Module not found: 'dgram' in /Users/liadrian/Dev/naive-bayes/node_modules/log4js/lib/appenders
@ ./~/log4js/lib/appenders/gelf.js 5:12-28
Error in ./~/log4js/lib/appenders/hipchat.js
Module not found: 'hipchat-notifier' in /Users/liadrian/Dev/naive-bayes/node_modules/log4js/lib/appenders
... and many more like the above
The problem
This is caused by a dependency on log4js, which for some reason has a lot of require statements in its appenders that are not declared in its own package.json file.
An example:
// node_modules/log4js/lib/appenders/clustered.js
var cluster = require('cluster');
But package.json
from the log4js module does not include cluster
as a dependency. As a result, when Webpack is trying to compile my app, an error is thrown for each of these delinquent requires (i.e. require statements for modules not listed in its package.json
dependency list).
The bottom line is: log4js is the problem.
The solution
After looking into this, I was able to find that log4js is only used within the Brill POS Tagger module. I recommend that we move away from log4js completely and replace those logging statements with normal console.log
or console.warn
statements instead.
I have already attempted to do this, and can confirm that this will indeed solve the problem.
I will submit a PR if the community agrees it is beneficial to the project.
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 18 (7 by maintainers)
np thanks for the pr!
@MichaelPaulukonis As great as NLP-Compromise is, it doesn’t have all the features that Natural has, such as the classifiers.
More importantly, the fact that Natural CAN be used client-side if we follow best practices from some of the more popular libraries mean that we shouldn’t exclude that from our roadmap.
The other consideration for this issue specifically is that we were depending on Log4JS which had missing dependencies in its package.json. By removing this dependency, we improved the codebase. I believe there are other logging libraries which don’t have this issue with the missing dependencies. Smart logging isn’t limited to the server-side, after all.
In conclusion, if your goal is to have a robust library that works well on the server-side, then you should attempt to make it at least somewhat usable on the browser-side. If there’s something we are using that only works on the server side, then maybe we are actually making our library LESS robust.
That being said, we probably can benefit from a more in-depth discussion on this. I’m not sure about the etiquette required of this repo, but you may want to start a separate issue on that.
Here’s a useful article on how to build different packages for browser vs server: https://nolanlawson.com/2017/01/09/how-to-write-a-javascript-package-for-both-node-and-the-browser/
One of the committers has to merge the PR, I cannot. But I support it.
Regards, Hugo