-
Notifications
You must be signed in to change notification settings - Fork 2.3k
Allow to override chai from the config #5974
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @farcaller ,
Thanks for the PR. I have a question.
Test instructions
require chai from the config and point config's chaiOverride to it. No default value is offered as the default is undefined.
Can you explain what chaiOverride
is, and which config it resides in?
my understanding is that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my understanding is that config is resolved to the truffle-config.js, so you can set up the chai import in there.
This PR introduces behavior based on a currently undocumented config setting. I think this PR should include the new setting, along with its a default value, so the complete feature implementation is captured in one place.
Thoughts, @eggplantzzz, @gnidan?
Sorry for the delay. Just getting back to this. I think this approach generally is fine, i.e., allowing users to specify a different package name in the truffle-config. I think we should do something like this, though, instead: module.exports = {
// ... rest of truffle-config.js
chai: {
package: "chai-as-promised"
}
} I think this might be the sort of thing we need to add to @truffle/config itself, also, but that sounds like more of an @eggplantzzz question. Oh, maybe |
Hey @farcaller, so if you can make the changes that @gnidan suggested we can move forward on this. The important part here is that the property in the Let us know if you need anything else! Also, if you feel like you won't have time to finish this, @cds-amal says he can bring it across the finish line. Just let us know :) |
So @farcaller, does the thumbs up mean you'd like to bring this across the finish line? Let us know either way. Like I said, we can take it up if you don't have the time. Thanks! |
The thumbs up is my seeing the feedback :) I’m out on holidays this whole month and will get back to coding in May. Sorry for the delays! |
Ok great! Enjoy your vacation! |
Hey @farcaller are you still interested in putting the rest of the PR together? Let us know, thanks! |
Sorry for the [extreme] delay. The PR is updated as per the feedback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, so as this currently is it actually has the user doing the require
in the config rather than just supplying the package name... is that what we want?
This is definitely more ideal, where @truffle/test's internals should do the But this might run into problems... if @truffle/test does So if we want to avoid this precedence concern, the way to do that is to put the I think this might be what we're stuck with. Thanks for raising this concern! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for following through on this @farcaller!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if this new way is good, then I'll approve it too!
PR description
Allow to override the chai instance from the config. This allows one to reduce the test boilerplate when chai plugins are used, e.g. this snippet could move to the config, instead of being repeated in every test:
Testing instructions
require chai from the config and point config's
chaiOverride
to it. No default value is offered as the default is undefined.Documentation
Trivial change, no docs required.
doc-change-required
label to this PR if documentation updates are required.Breaking changes and new features
Non-breaking.
breaking-change
andnew-feature
labels for the appropriate packages.