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

Support a meteor.testModule section in application package.json files. #9714

Merged
merged 12 commits into from Mar 1, 2018

Conversation

Projects
None yet
2 participants
@benjamn
Member

benjamn commented Mar 1, 2018

Similar to #9690, this PR adds support for a meteor.testModule configuration in application package.json files, allowing application developers complete control over what test files should load when running meteor test to test their applications.

Setting meteor.testModule is a great way to specify test entry points explicitly, rather than relying on Meteor's isTestFilePath heuristics. However, this feature is entirely opt-in, so the old behavior is preserved if you do not configure meteor.testModule.

The syntax is identical to meteor.mainModule, so you can set a different 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.

Different testModules for client and server:

"meteor": {
  "testModule": {
    "client": "client/tests.js",
    "server": "server/tests.js"
  }
}

Same testModule for both client and server:

"meteor": {
  "testModule": "tests.js"
}

Server tests without any client tests (note that simply omitting the "client" property would cause tests to behave as if there was no meteor.testModule on the client):

"meteor": {
  "testModule": {
    "client": false,
    "server": "server/tests.js"
  }
}

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 due to 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. If you run meteor test --full-app, the meteor.mainModule module(s) will be loaded eagerly in addition to the meteor.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.

benjamn added some commits Feb 27, 2018

Allow meteor.mainModule.{client,server} === false for no entry point.
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.
Also support meteor.testModule to configure test entry points.
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.
Improve meteor.mainModule arch discovery in tests.
If config.mainModule.client === false, then mainId should === false.
Stop using _inferFileOptions for package files.
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.

@benjamn benjamn added this to the Release 1.6.2 milestone Mar 1, 2018

@benjamn benjamn merged commit 2e8b359 into devel Mar 1, 2018

2 checks passed

CLA Author has signed the Meteor CLA.
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details

benjamn added a commit that referenced this pull request Mar 1, 2018

Use meteor.{mainModule,testModule} for `meteor create` starter apps.
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.
@pravdomil

This comment has been minimized.

Contributor

pravdomil commented Mar 7, 2018

that would be handy also for packages in node_modules, first step in transition from atmosphere packages, have anybody try something like this?

@benjamn

This comment has been minimized.

Member

benjamn commented Mar 7, 2018

@pravdomil I haven't been thinking about that recently, but you're right, we could potentially scan node_modules packages to find those that have a meteor section in package.json, and run those entry points on application startup (server) and/or page load (client).

That's another great reason to use Meteor-specific configuration instead of just reusing the main or browser fields in package.json files, since every npm package has those already.

@pravdomil

This comment has been minimized.

Contributor

pravdomil commented Mar 7, 2018

@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.

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