-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Support a meteor.testModule section in application package.json files. #9714
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
Conversation
Determining if Meteor package files should be loaded lazily or eagerly is a lot easier than doing so for application files, so we should just do that separately, to avoid any risk of application directory layout logic interfering with package behavior.
If meteor.mainModule.{client,server,...} === false, no modules will be loaded eagerly for that architecture. This is useful if you have an app with no special app/{client,server} directory structure and you want to specify an entry point for just the client (or just the server), without accidentally loading everything on the other architecture.
If config.mainModule.client === false, then mainId should === false.
Setting meteor.testModule is a great way to specify test entry points explicitly, rather than relying on Meteor's isTestFilePath heuristics: https://github.com/meteor/meteor/blob/devel/tools/isobuild/test-files.js The syntax is identical to meteor.mainModule, so you can set an explicit meteor.testModule.{client,server,...} for each platform. If a testModule is not specified for a platform, then Meteor's existing rules about test file paths apply for that platform, as before. If a testModule is specified, that module will always be loaded eagerly when running `meteor test`, in addition to any other modules that load eagerly because of meteor.mainModule or other rules regarding module loading. If you run `meteor test` without the `--full-app` option, then no application JS modules other than the testModule (and any modules imported by it) will be loaded eagerly.
In order for Meteor to maintain its commitment to being a zero-configuration tool, any configuration options that we add must come pre-configured in the best way possible for newly created apps. In particular, the default new Meteor app must contain a reasonable testing story, or else we are signalling to the community that testing is an afterthought. With that said, this PR is still a work in progress. I welcome your feedback on how best to configure the default `meteor create` starter app. Builds on #9690 and #9714.
that would be handy also for packages in node_modules, first step in transition from atmosphere packages, have anybody try something like this? |
@pravdomil I haven't been thinking about that recently, but you're right, we could potentially scan That's another great reason to use Meteor-specific configuration instead of just reusing the |
@benjamn I'm writing plugin that does exactly that, since I want to move my repos to npm, can you give me some hints where to start? Since probably you know the codebase a lot better. |
Can this be used in an effortless way if you have a lot of test files? For example, I'd like to be able to import all tests from a few directories, without having a massive import list in this testModule file. |
This snippet should help you. Just put it into a file referenced by this feature: const glob = require('glob');
const path = require('path');
const projectPath = '/Users/simon/my-project-folder/';
glob.sync(`${projectPath}**/*.test.js`).forEach((file) => {
require(path.resolve(file));
}); I just used the library I had to define the full path because tests are run in a built meteor app - somewhere in a temporary directory. It includes only the files referenced in EDIT: Once this get's approved you'd not even need to include the full path, but use the environment variable instead: #10666 |
@SimonSimCity Looks great! I thought about using Unfortunately the Are you sure there's no combo of |
@Floriferous You're on the wrong track here. It has nothing to do with You can - however - do this by setting an env variable yourself by calling |
Similar to #9690, this PR adds support for a
meteor.testModule
configuration in applicationpackage.json
files, allowing application developers complete control over what test files should load when runningmeteor test
to test their applications.Setting
meteor.testModule
is a great way to specify test entry points explicitly, rather than relying on Meteor'sisTestFilePath
heuristics. However, this feature is entirely opt-in, so the old behavior is preserved if you do not configuremeteor.testModule
.The syntax is identical to
meteor.mainModule
, so you can set a differentmeteor.testModule.{client,server,...}
for each platform. If atestModule
is not specified for a platform, then Meteor's existing rules about test file paths apply for that platform, as before.Different
testModule
s for client and server:Same
testModule
for both client and server:Server tests without any client tests (note that simply omitting the
"client"
property would cause tests to behave as if there was nometeor.testModule
on the client):If a
testModule
is specified, that module will always be loaded eagerly when runningmeteor test
, in addition to any other modules that load eagerly due tometeor.mainModule
or other rules regarding module loading. If you runmeteor test
without the--full-app
option, then no application JS modules other than thetestModule
(and any modules imported by it) will be loaded eagerly. If you runmeteor test --full-app
, themeteor.mainModule
module(s) will be loaded eagerly in addition to themeteor.testModule
module(s).The module(s) specified by
meteor.testModule
can import other test modules at runtime, so you can still distribute test files across your codebase; just make sure you import the ones you want to run.