Chai Roadmap

TL;DR

Over the next few versions we’re going to try to do the following:

• Refactor messages to support advanced template strings (per chaijs/chai#393)
• Refactor plugin declarations to support new interfaces (per chaijs/chai#117)
• Split out chai codebase into various modules
• Turn chai into a metapackage which combines these modules

Refactor Messages

@svallory has done some excellent work into refactoring the message syntax for chai assertions. This will make writing plugins simpler, as the need for message variants is removed.

See chaijs/chai#393 for more.

Refactor plugin declarations

Right now the plugin system is simple to use, and has lead to a successful plugin community. But it could be better.

Assertions should declare the flags they use in an up-front manner, allowing deeper introspection for interfaces. This will allow us to put effort into making interfaces which are pain points for the community - such as an assert interface that works with <=IE8, and expect/should interfaces which use method assertions over property assertions.

Two of the biggest causes of fragmentation of chai users is due to low browser support, and the property assertions - which spawns off codebases like the following:

• hapijs/code
• rowanmanning/proclaim
• moll/js-must
• wrumsby/ristretto

While we can’t be all things to all people, some of these libraries exist purely because Chai has failed them, and so we see a lot of duplication of effort.

Some of this has been discussed in chaijs/chai#117.

Split out chai codebase into various modules

We’ve been putting efforts into splitting chai out into smaller modules, and it’s been working well - but I think we can go further. The way I see things, we can split chai into the following:

• chai-core (plugin loader interface, lib/assert, lib/chai/utils.[add/overwrite]*.js)
• chai-common-assertions (existing assertions, lib/chai/core/assertions.js)
• message-formatter (lib/chai/utils/getMessage.js, and @svallory’s work)
• checkError (complex logic within lib/chai/core/assertions.js .throw assertion)
• loupe (lib/chai/utils/inspect.js, old code exists as loupe, but needs updating and removing from chai proper)
• AssertionError (already modularised as assertion-error)
• type-detect (already modularised as type-detect)
• pathval (lib/chai/utils/getPathInfo, old code exists as pathval, but needs updating and removing from chai proper)
• interfaces
  • assert (lib/chai/interface/assert)
  • expect (lib/chai/interface/expect)
  • should (lib/chai/interface/should)
  • assert-legacy (potential new interface for older browsers)
  • expect-method (“jshint friendly expect”)
  • should-method (“jshint friendly should”)

Becoming more modular, we can also hope to facilitate some new and interesting use cases of our work, such as described in chaijs/chai#346

Chai metapackage

With modules pulled out of the main chai codebase, we can effectively turn the chai package into a metapackage of the rest of chai. It’ll still be a first class part of chai, and we’d funnel all issues to this - but by having discrete modules for each part, we give the community a chance to pick and chose elements. We can innovate in areas, like having a chai-lite module which can be used in older browsers, while chai proper can innovate upon evergreen browsers.

Roadmap:

Based on the above, I see the roadmap as follows:

3.0.0

• Move type-detect into its own library (thanks @davelosert!).

4.0.0

• Move pathval into its own module (thanks @lucasfcosta!). [Issue: #737]
• Improve deep-eql for ES6 and more. [#837]
• Move checkError into its own module (thanks @lucasfcosta!). [#683]

5.0.0

• Switch to new declarative plugin syntax (where plugins define the flags they support upfront) [WIP #585]
• Switch to new chai message formatting
• Move loupe into its own module. [WIP]

5.1.0

• Trial new interfaces, assert-legacy, expect-methods and should-methods.
• Move chai-core into its own module.
• Move chai-common-assertions into its own module.

[lucasfcosta]

@keithamus @meeber @shvaikalesh Hello everyone, so, now that I’ve got access to the shared folder, I talked to @keithamus this morning and he authorized me to release it, so, since I’ll meet @vieiralucas tonight at college we will take some time to do it together and make sure everything goes right.

The tag’s name will be canary, is everyone okay with that? Please let me know if you want to schedule another date for a release or anything like that. Thanks everyone 😄

[lucasfcosta]

@keithamus @meeber @shvaikalesh @vieiralucas Hello everyone! So, I noticed we’ve got plenty pending PRs, thus I think maybe we should start cutting things off for the 4.x.x release, specially breaking changes.

IMO we could start accepting breaking PRs into a 5.x.x branch and add only bugfixes and small changes to master. Focusing on getting the next major version out would greatly help us getting feedback from users and therefore (IMO) should be prioritized.

Let me know if you disagree and please share your thoughts, I just want to make sure we’re all on the same page 😄