A linter to catch the bugs and then go back and fix them is more work than just making it not possible to have the bug exist. Also, the lint you are talking about is based on a typographic convention that you could easily get wrong. For instance, the linter won't catch the bug in this snippet:
In your example you have two "bugs", you're not capitalizing the constructor name and you're not using `new`. I would have to make two separate mistakes to reproduce the issue you're talking about.
The only way I'd make the first mistake is if I was unfamiliar with `your-class`'s API, so nothing can save me there.
Nitpick, on the nothing can save me there part. This is arguably a failure of `your-class`'s API.
A file exposing a class SHOULD either wrap it: `module.exports = function () { return new YourClass(); }` or use `if (!(this instanceof YourClass)) return new YourClass()` guards in the constructor to stop users of a class having to worry about whether or not to use new.
At least this seems to be the convention many module publishers seem to adhere to.
Yeah, but that falls under epediaman's "Stop over-engineering. YAGNI!" quote.
If you want the benefits of `new` without exposing your interface, you should totally wrap it.
But if you're going to have boilerplate like that for code that not's performance critical (and most of it is not), why not just go for Object.create() and returning the instance yourself. Less action at a distance.
Comments
A linter to catch the bugs and then go back and fix them is more work than just making it not possible to have the bug exist. Also, the lint you are talking about is based on a typographic convention that you could easily get wrong. For instance, the linter won't catch the bug in this snippet:
``` var yourClass = require('your-class');
var myInstance = yourClass(); ```
In your example you have two "bugs", you're not capitalizing the constructor name and you're not using `new`. I would have to make two separate mistakes to reproduce the issue you're talking about.
The only way I'd make the first mistake is if I was unfamiliar with `your-class`'s API, so nothing can save me there.
JSHint would catch the second one.
Nitpick, on the nothing can save me there part. This is arguably a failure of `your-class`'s API.
A file exposing a class SHOULD either wrap it: `module.exports = function () { return new YourClass(); }` or use `if (!(this instanceof YourClass)) return new YourClass()` guards in the constructor to stop users of a class having to worry about whether or not to use new.
At least this seems to be the convention many module publishers seem to adhere to.
Yeah, but that falls under epediaman's "Stop over-engineering. YAGNI!" quote.
If you want the benefits of `new` without exposing your interface, you should totally wrap it.
But if you're going to have boilerplate like that for code that not's performance critical (and most of it is not), why not just go for Object.create() and returning the instance yourself. Less action at a distance.