Release tooling

[shvaikalesh]

I understand that what I am suggesting is quite big and demands a long discussion, but nevertheless:

1. Use semantic-release instead of custom release logic in Makefile.
2. Use Rollup so we don't ship whole package.json with chai and keep git history of lib/chai.js clean from version bumps.
3. Move bundling & tests to npm scripts. Syntax of Makefile may be considered unwelcoming to JS developers.

[meeber]

Will offer more later, but just want to note for now that (just like adding linting), I consider all of these post-v4 considerations.

[keithamus]

Thanks for making this issue @shvaikalesh. Just FYI, the modules we've been splitting out have been using Browserify, with npm scripts and semantic-release. Take a look at https://github.com/chaijs/check-error, https://github.com/chaijs/pathval, chaijs/deep-eql#14, https://github.com/chaijs/type-detect.

If we want to add new tooling, like Rollup, I think we should experiment in the smaller modules for now. While these modules are still integral to chai, they have a much smaller scope and so should be easier to verify results.

[keithamus]

As an aside @shvaikalesh; how would you like to join the chai team as a maintainer? Being a maintainer will give you the ability to approve or reject changes, and close or reopen issues. As you've probably seen already, we ensure every PR is approved by at least 2 maintainers, and we have some maintainers who are more active than others - you will not be expected to have a certain amount of output. Thoughts?

[meeber]

@shvaikalesh You'd also be required to legally change your first name to Lucas within 6 months of joining the team, but that's just a minor detail.

[lucasfcosta]

I agree with @meeber and @keithamus. Let's add these changes gradually after 4.x.x.
Also, I'd like to reinforce @keithamus invite, if you feel like it please add your name to our MAINTAINERS file so LGTM will be able to recognize your approval.
It would be great to have you here more often 😄

Chai's project will be able to move pretty fast now we've got such awesome new contributors 😄

[shvaikalesh]

@keithamus Thanks for the links, I am all for doing this gradually and after 4.0 release. Chai is awesome library with great ecosystem and API, well-written and technically sophisticated (accessors, proxies and other stuff). Awesome work, guys 👍. Would be glad to join the Chai team.

#824

[meeber]

I'd like to bring up linting again. We've discussed in the past about waiting to introduce linting until we've broken out more of the code into modules. However, my current feeling is that the Chai Team (self-included) have been extra busy lately outside of Chai, and it's unlikely we'll get to the module migration anytime soon. I think we should push forward with linting now.

In addition to ESLint, I think it's worth taking a look at https://github.com/prettier/prettier. I like the idea of helping to bring stylistic consistency across major open source projects, especially in regard to a lot of the highly subjective style preferences.

(This also means closing #1042 and #1052, since those changes would be resolved via linting.)

Pinging @shvaikalesh, @keithamus, @lucasfcosta, @vieiralucas

[keithamus]

My worry of bringing it in, is it causes many large diffs while we fix a bunch of huge files. The purpose of waiting til we split out modules is that as modules are split, they follow better practises of many-small-files and also it means less noise here. That being said, those are just my feelings and if everyone else feels we should move to using eslint right away, then let's do that.

[lucasfcosta]

I have added these tooling-related tasks to our roadmap project board and therefore I'm closing this issue to cleanup the house for the next release.

These are the cards related to it:

• https://github.com/chaijs/chai/projects/2#card-10444042
• https://github.com/chaijs/chai/projects/2#card-10463894
• https://github.com/chaijs/chai/projects/2#card-10463882