Meteor test-packages

We have a number of meteor applications that consume a quite a few local, unpublished meteor packages. They all consume different subsets of these packages but there is a lot of re-use (hence the decision to use packages). These packages are all local, so there’s one ‘version’ of all of them for a given source tree checkout.

However, it seems that the meteor test-packages model works very strangely: it seems that meteor test-packages has to be run from an actual meteor app’s directory and it will inherit the npm packages of that application. This is very problematic for a couple of reasons:

  • if I want to make sure all of our packages are tested, I have to run meteor test-packages in every applications’ directory, meaning a very significant amount of duplicated testing since packages are shared.

  • a lot of npm packages are implicitly pulled in by meteor packages we have no control over (as per the meteor guidelines) and each particular package will come from the package.json of the app whose directory the test-packages command is being run from, which is NOT what we want. In fact, there’s no other way to pull in some of these packages (react-template-helper is an example of this).

This model for testing packages is so counter-intuitive. If I write a package and want to test it, there should be no requirement for an application - I should be able to test all our local packages, without any application, with a single command (as long as I setup METEOR_PACKAGE_DIRS appropriately). It seems that requiring an application is the meteor model, especially in recent developments. Any package that follows the meteor guidelines on peer npm dependencies cannot be tested outside the directory of an application that has npm-installed the dependencies because its node_modules has to be used by the generated test app to take care of the implicit dependencies.

Is there any plan to get rid of this requirement to run meteor test-packages from an app directory? I’m sure this was not the original intent and it probably became an accidental, undocumented requirement when the package.json support was added to apps.

Am I ever going to be able to run meteor test-packages outside an app’s directory ever again so I can verify the package logic for all our apps in one shot?

1 Like

8 month after the topic was posted, we’ve started covering our local packages with unit tests and faced all the same problems. Currently our case is simpler, as we have a single app and multiple local packages. But eventually we might have multiple apps sharing the same local packages. I just want to have a solid plan for when that time comes.
Could it be that Meteor packages testing has stopped evolving due to the fact it’s recommended to eliminate using Meteor packages in favor of Node packages? Do we observe a fall of Meteor packages era?