-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
🚀 Feature: Plugin API #1457
Comments
Currently, we don't have the resources to add many features users want, because we cannot afford to take on more of a maintenance burden. In order to allow users to add features that are not available in Mocha core, we need a set of well-documented and easy-to-use plugin APIs. I'm thinking we'll need the following:
Ideas/comments/suggestions? I'll propose some more specifics later. |
Extracting any reporters or interfaces from the core will cause a major bump |
It would be great if this plugin architecture supported adding global before/after hooks! |
Some thoughts on the above proposal:
// my-cool-plugin.js
module.exports = function(mocha) {
mocha.registerReporter();
mocha.addCliOption();
// etc
} I would suggest that core-module-replacement and inter-plugin-communication not be included in an initial release, as they're quite tricky and it would be more important to get the basic mechanisms in first. A possible initial featureset could be:
One way to allow plugins to specify extra options but also be parsed from options is to do one pass over argv to get the plugin list, then load them, then do another pass to get the full options list. |
@glenjamin Thanks for the input. I'm going to fiddle with this a bit. |
First, I've always like chai's plugin architecture: chai.use(require('some-chai-plugin')); That should not preclude functions like So spec should be something like this:
|
@jamestalmage Mocha, on the other hand, allows CLI options or a What do you think? Personally, I think |
I wasn't suggesting that you NOT provide a command line. Just suggesting what I thought was a good API. I'm not so sure about JSON/YAML. They end up being a bit too restrictive. I like how karma handles config: // karma.conf.js
module.exports = function(karma) {
karma.set(
/* ... */
);
} That tiny bit of extra verbosity provides all kinds of power: karma.set({
browsers: [process.env.TRAVIS ? 'Firefox' : 'Chrome']
}); This would be super handy for say, skipping certain tests that were part of a PR because they required secure variables on travis (which are not available to PR's for security reasons). Angulars karma configs make heavy use of this power and provide a good example of an |
Fwiw I like that mocha.opts forces all config to also be available on the command line. |
@glenjamin I don't think there's anything wrong with making all of core config available on the command line, but I don't think you want to force that on every plugin. Certainly provide a mechanism for plugins to digest command line args. |
@jamestalmage I'm in disagreement--I understand that as a
Not sure where I gave you this impression..? Anyway, I'm of the opinion this sort of thing (and likely other collaborators as well):
...should not be handled by Mocha; it wades into "task runner"/ I'd probably support
The config file should allow plugin-specific configuration which may or may not be applicable to the command line; think browser-only reporters. UPDATE: No, browser reporters won't have access to the config file, so yeah, I don't envision anything in the config file that wouldn't be available on the command line. 😄 |
@boneskull Yeah, I pretty much anticipated this would be your response, but I'm a masochist, so I'm going to keep arguing 😜 .
If you were ever silly enough to make your build script complicated enough where you did feel so compelled, would you rather write unit tests against a bash script, a Makefile, or a javascript module? IMO,
To be clear, in my example all karma sees is
As for keeping mocha simple, I couldn't agree more, but I would think a var config = require('config.json');
// vs
var config = require('config.js')(mocha); |
Why would you prevent browser reporters from accessing the config file? |
@jamestalmage Because browser reporters run in the browser and do not have access to the filesystem. |
Yeah, but couldn't you bundle it right alongside all the sources? That's certainly an argument for sticking with JSON. |
err, nevermind. I'm conflating mochas abilities with |
It'd be neat if it were possible to use mocha programmatically without it requiring all the tty/shell related dependencies. I integrated Mocha in ArangoDB to allow us to execute tests in ArangoDB's JavaScript environment (which is mostly compatible with node modules) but had to shim several dependencies as well as some internals like I think it'd be a good idea to extract the mocha runner and interfaces and have them separate from the CLI (which could then handle features like plugin auto-loading). It'd also be nice if the interfaces used |
oh wait, this is #1457. |
@pluma Anyway, it's going to be iterative. I'm not sure we can release it iteratively, but the first thing I'm focusing on is providing several common interfaces for reporters of different types. Currently I have a
Suggestions welcome! |
Maybe domictarr/rc could be useful to implementing a configuration file easily |
Definitely. I forked it to rc-yaml which adds, well, YAML support. |
Is this issue still being considered? |
I've been linking issues to this one that seem relevant. There are ... quite a few 🫠. But given how many use cases folks have asked for Mocha that would be solveable by a plugin API, they're all required reading to submit a proposal for this. #4116 has some very good notes too. |
We need plugin API(s).
More to follow.
The text was updated successfully, but these errors were encountered: