Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The role of chai and chai plugins #605

Closed
keithamus opened this issue Jan 30, 2016 · 5 comments
Closed

The role of chai and chai plugins #605

keithamus opened this issue Jan 30, 2016 · 5 comments

Comments

@keithamus
Copy link
Member

One of the reasons why Chai is my favourite assertion library is its amazing ecosystem, which includes a rich collection of plugins for all the extra functionality you might want. Sadly though, we sometimes have a blind spot for our plugins, and end up reimplementing them in core. This really sucks because we're pulling the rug from under our hard working contributors who spend time and effort solving problems, which then sometimes end up as incomplete half solutions in chai. The most notable example of this is @timruffles' chai-change & @matthijsgroen's chai-changes (see #218, #339, #428 and #544 for history there).

I've mentioned in #428 that I'd like to see chai-core cover JavaScript builtins - meaning Strings, Numbers, Booleans, Objects, Arrays (and TypedArrays), Functions, Dates, and the new builtins like Promises & Symbols. Things that you can do with the native API (like, for example, checking if an Object isFrozen), there should be a chai assertion for - which is slowly but surely happening (we added support for Object.isFrozen in 3.2.0).

However, what we don't want to do is step on existing plugins which offer the same functionality - this would be a mistake. I think an important precedent needs to be set that - whenever we encroach on the territory of a chai plugin, we reach out to the authors and try to fold the plugin to the chaijs org, with the hope of eventually including that plugin as part of chai core. With the ideas inside #457 (Roadmap issue) - that the chaijs/chai repo becomes a meta repo of plugins, I think this looks like a very achievable goal. We could look toward folding in plugins like chai-change, chai-string, chai-match into the chaijs org while keeping the original authorship and lifting plugins instead of stepping on them.

In addition to this, I'd like improve our documentation around contributing and plugin authorship - and outline a clear separation of where we'd welcome PRs vs plugins. Whereby plugins become a "userland" feature, for example chai-spies, chai-react, chai-jquery etc.

I want to keep this issue around to get some feedback from plugin authors & chai users & contributors - to field some opinions, so please, if you see this and are a chai user - comment your 2¢!

@mrgenixus
Copy link

Might it be worthwhile for plugin authors to create an issue or pull request on chai core for including plugins as core so that the core team could positively identify whether the plugin is something that might be potentially pulled in (based on whether it deals with core javascript considerations, or not) or which will not be included in core? Would this be an effective way to manage the kind of encroachment described?

@sukrosono
Copy link
Contributor

@mrgenixus 👍

@keithamus

I'd like improve our documentation around contributing and plugin authorship

maybe i can work on it 😄

@keithamus
Copy link
Member Author

I'd typically welcome changes but I'm not sure where or how we should go about this yet. I'd like to spend more time discussing it with plugin authors, finding the right ways to make sure authors are not retrained in terms of flexibility, but don't feel as though chai steamrolls their plugins. This is something which will take more time before we can write a set of docs I think.

@keithamus
Copy link
Member Author

@brutalcrozt if you want to find some things to work on, you could have a look at our pull requests wanted label, starting with the easy-fix issues.

@lucasfcosta
Copy link
Member

As me and @keithamus discussed this weekend, plugins will no longer be treated as an external third-party when we get to v5. They'll instead become first class citizens and we'll make sure that we make it as easy for plugin authors to add assertions as it is for us to write new ones in the lib's core.

Due to that and to house-cleaning, I'm closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants