ci(release): publish to NPM

[jeffrose]

Expected Behavior

I should be able to install the plugin from NPM.

Current Behavior

It is not available in NPM.

$ npm install eslint-plugin-crc
npm ERR! Darwin 16.7.0
npm ERR! argv "/Users/jeffrose/.nvm/versions/node/v6.10.2/bin/node" "/Users/jeffrose/.nvm/versions/node/v6.10.2/bin/npm" "install" "eslint-plugin-crc"
npm ERR! node v6.10.2
npm ERR! npm  v4.3.0
npm ERR! code E404

npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/eslint-plugin-crc
npm ERR! 404 
npm ERR! 404  'eslint-plugin-crc' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

[gregswindle]

Hi, @jeffrose , thanks for your interest! To be honest, I'm not sure whether this is ready for NPM: the codebase is for a whitepaper I'm writing. It also needs refactoring.

If, however, you'd like me to publish it, I'm open to the suggestion.

[jeffrose]

Hello @gregswindle , I guess it depends on the functionality that's currently available. I am mostly interested in code smell detection and static analysis. If you think it's not quite ready for public consumption, I understand. If part of the functionality works, I don't seem harm in publishing as long as the version number reflects that.

[gregswindle]

I appreciate the prompting, @jeffrose. I'll dust off eslint-plugin-crc this weekend and see how far I can get. In the meantime, if you're interested in some of the mechanics under the hood, please take a look at the GitBook Refactoring JavaScript I'm using (with RunKit examples) to make notes as I work on this.

I'll keep you posted and shoot for a 0.1.0 version. Thanks again.

[gregswindle]

Hi, @jeffrose. Update, as promised: I didn't get a chance to work on eslint-plugin-crc this weekend. I will, however, take a look this week. Thanks for your patience.

[jeffrose]

Hey @gregswindle , you've written one of the more thorough explorations of inheritance I've seen. Unless I overlooked it, one thing that might be worth calling out is how the different kinds of inheritance produce functionally equivalent but different results.

function FooBar(){
    this.bar = function(){}
}
FooBar.prototype.foo = function(){}

console.log( new FooBar().foo === new FooBar().foo ); // true
console.log( new FooBar().bar === new FooBar().bar ); // false

When doing prototypal inheritance, the class instances are sharing a function. When doing constructor inheritance, the class instances are getting their own copy.

In terms of best practices, you typically want to inherit properties via constructor inheritance and methods via prototypal inheritance.

No worries about the plugin. While ESLint provides a rule for cyclomatic complexity, there is a gap to be filled for other kinds of analysis.

[gregswindle]

Excellent point, @jeffrose! Thanks for putting a finer point to prototypal vs. constructor inheritance. If you don't mind, I'll incorporate your example (and attribute it to you) in the documentation. In fact, I think I smell a rule called prefer-constructor-inheritance somewhere....

And thank you for pointing out the gap; that's motivating.

[gregswindle]

Hi, @jeffrose.

Status

I'm gonna try and deliver MVP1 of eslint-plugin-crc by end-of-year 2017. The refactor/#41-rule-based-crc-models branch is coming along nicely, and I've pruned tons of unnecessary dependencies.

Request

Would you be willing to review PRs? If so, I'd love to add you as a collaborator. If not, that's cool: I understand and value your time.