Why a "deugOnly" package cannot register a build plugin?

apendua · December 20, 2015, 2:07pm

I am just wondering if there’s a good reason to have that constraint or is it an arbitrary decision?

Example use-case

Let’s assume I want a tool that injects fixtures to my development database. I would like to have some files in which I describes those fixtures, e.g.

myproject/
  fixtures/
    users.fixture
    items.fixture

possibly in some custom “language”. It seems like a good idea to have a debugOnly package that consumes those files and produces Javascript code that will be responsible for altering the database if it’s necessary. Of course I don’t want that package to include anything in the production build.

Does it sound reasonable?

It seems to me that this is not possible to achieve this at the moment because if I set debugOnly flag to my package the meteor build complains about not being able to register build plugin.

apendua · December 20, 2015, 2:27pm

A related but not equivalent question:

Is there a way to alter the behavior of a build plugin based on the type of build, i.e. production vs. “debug”?

apendua · December 20, 2015, 2:52pm

Looks like I’ve found the answer here:

github.com

meteor/meteor/blob/60e378f8f60200276b5f5429faa18230f1398be5/tools/isobuild/package-source.js#L1044-L1052


// We want the "debug mode" to be a property of the *bundle* operation
// (turning a set of packages, including the app, into a star), not the
// *compile* operation (turning a package source into an isopack). This is
// so we don't have to publish two versions of each package. But we have no
// way to mark a file in an isopack as being the result of running a plugin
// from a debugOnly dependency, and so there is no way to tell which files
// to exclude in production mode from a published package. Eventually, we'll
// add such a flag to the isopack format, but until then we'll sidestep the
// issue by disallowing build plugins in debugOnly packages.