Try out a preview of batch build plugins (and other 1.2 features)!


@glasser on linux, console.log() output in the console comes corrupted. End of lines have character added each time the plugin restart (after a plugin code modification).
The characters seems to come from a platform description (as if there was some sort of buffer overflow), i get things like “owser” (end of browser) or “ux.x86_64” (end of linux.x86_64) if that can help.


Any idea what this error means that I encountered trying PLUGINS-PREVIEW@1 compared to METEOR@ I’m not sure how to debug this:

I20150724-15:56:32.498(-5)? Exception in Mongo write: Error: fence has already activated -- too late to add a callback
I20150724-15:56:32.498(-5)?     at [object Object]._.extend.onBeforeFire (packages/ddp-server/writefence.js:69:1)
I20150724-15:56:32.498(-5)?     at Object.callback (packages/mongo/oplog_observe_driver.js:154:1)
I20150724-15:56:32.498(-5)?     at packages/ddp-server/crossbar.js:109:1
I20150724-15:56:32.499(-5)?     at Array.forEach (native)
I20150724-15:56:32.499(-5)?     at Function._.each._.forEach (packages/underscore/underscore.js:105:1)
I20150724-15:56:32.499(-5)?     at [object Object] (packages/ddp-server/crossbar.js:107:1)
I20150724-15:56:32.499(-5)?     at [object Object].kadira_Crossbar_fire [as fire] (packages/meteorhacks_kadira/packages/meteorhacks_kadira.js:3348:1)
I20150724-15:56:32.499(-5)?     at Object.Meteor.refresh (packages/ddp-server/server_convenience.js:9:1)
I20150724-15:56:32.499(-5)?     at refresh (packages/mongo/mongo_driver.js:349:1)
I20150724-15:56:32.499(-5)?     at packages/mongo/mongo_driver.js:309:1
I20150724-15:56:32.499(-5)?     at runWithEnvironment (packages/meteor/dynamics_nodejs.js:108:1)


Huh, can you provide a more detailed replication for this? This isn’t something I’ve seen.


@jasonxeno Similarly, can you provide a more specific reproduction here? This could have something to do with an optimization for Livequery:

I see kadira mentioned in that stack trace. Can you reproduce this without Kadira? I know Kadira has some hacks in places that we don’t provide hooks, and the commit above could have made a difference. cc @arunoda


Actually, this is a marker we add for the CPU profiler. I don’t think that would make a difference.

Here’s the code we used:


@glasser Thank you for the hint. I’m getting the same error without Kadira. I’m getting this in a complex area of my code, so I’ll spend some time trying to test simulated isolated pieces of it for a possible reproduction.

In the mean time, I’ll describe what my code is doing in case it helps, the part where the error occurs is when the server makes 5 async HTTP POST calls at the same time, then processes an array of 5 objects from the result of each call, and saves each object as a separate document in a collection in a loop. It errors out after only 1 document is saved after the first HTTP result is returned, and when it tries to save the next document. The whole process goes through several calls and functions.


The new PLUGINS-PREVIEW@2 pre-release has been pushed. The updates from the previous preview:

  • fixed some importing from imports bugs in Stylus
  • QA’d and tested on Windows (fixed bugs relevant to handling paths)
  • all build plugins should prefer using Plugin.fs and Plugin.path that work with the standard paths (/C/some path/file.exe as opposed to C:\some path\files.exe)
  • fixed import in accounts-ui's less file
  • a jscript fix for the babel-compiler package
  • renewed dev-bundle working well for Windows

What's new for CompileStep API in 1.2?
Any Meteor 1.2 preview build available?

I also ran into an instance where I’m getting the Mongo write fence error. This occurred when testing, using Velocity and Mocha.

Exception in Mongo write: Error: fence has already activated -- too late to add a callback
I20150729-05:24:28.230(-4)?     at [object Object]._.extend.onBeforeFire (packages/ddp-server/writefence.js:69:1)
I20150729-05:24:28.230(-4)?     at Object.callback (packages/mongo/oplog_observe_driver.js:154:1)
I20150729-05:24:28.231(-4)?     at packages/ddp-server/crossbar.js:109:1
I20150729-05:24:28.231(-4)?     at Array.forEach (native)
I20150729-05:24:28.231(-4)?     at Function._.each._.forEach (packages/underscore/underscore.js:105:1)
I20150729-05:24:28.231(-4)?     at [object Object] (packages/ddp-server/crossbar.js:107:1)
I20150729-05:24:28.231(-4)?     at Object.Meteor.refresh (packages/ddp-server/server_convenience.js:9:1)
I20150729-05:24:28.232(-4)?     at packages/mongo/mongo_driver.js:374:1
I20150729-05:24:28.232(-4)?     at Array.forEach (native)
I20150729-05:24:28.233(-4)?     at Function._.each._.forEach (packages/underscore/underscore.js:105:1)

Here’s a recreation:

The key file is foo-test.js

describe('Running some tests', () => {
  it('should run', (done) => {'dropThings', (err, res) => {
      console.log("test finished");

This will run fine on the client, not triggering any error. But running it on the server throws that Mongo error. Other observations:

  • It only happens when using in an it, before, or beforeEach block – not if it’s just in a describe block.
  • It doesn’t happen in the application. Checkout sandbox.js to see that – does the same thing, no problem
  • Operation on the collection doesn’t matter. I’ve tried removing and inserting, it still throws the same error
  • The error comes after the test has finished. I’ll see test finished in the console before I see the Mongo write fence error


@louis Let’s open a separate GitHub issue to track this down. It looks relevant to a recently merged optimization to oplog driver.


@glasser @slava

Do we need to specify isobuild:compiler-plugin@1.0.0 as a dependency if we use Plugin.registerCompiler? I thought I read that somewhere. Or is that if we’re using the caching-compiler classes?


Yes @joe


@vjau Ah, good to know. Thanks for the link! :smile:


Yes, this is done so older versions of Meteor tool don’t even try to use the new API.

How to add a new file type that will be auto refreshed (run) in Meteor?

@slava @glasser What if the InputFile.add* methods could accept an option called passThrough that would allow other compilers to continue processing files that are marked as passThrough: true from the previous compiler? That might be useful in order to use multiple compilers on the same types of files.


Maybe there can be a file inside path/to/your/app/.meteor where we can specify the order of compilers.

Question to MDG: Building routing into core

This would be great! I’m working on a package that preprocesses js/jsx/html and compiles it into valid React or Angular2 from Blaze.

This package could also be used to extend React and Angular with Handlebars (or Spacebars).

Either to simplify the transitions between the frameworks or for performance comparisons on the same codebase.

But there could also be packages that help pull out translations and replaces the english translation with a valid translation key in a new translation configuration file.


You should check out, I’ve completed some working prototypes with build pipelines for HTML and Ecmascript, allowing build plugin authors access to add to the pipeline and alter the order.

I’ve built it for the latest release of meteor:

You can test it out using the latest release, containing a lot of refactors to how templating is done compared to PLUGINS-PREVIEW@1

meteor --release ANUBHAV-ERROR-APP-TEST@1

You will first need to remove templating and ecmascript as they now are in the pipeline instead. Then you can add the pipeline versions.

meteor add pipeline:templating
meteor add pipeline:ecmascript

If you want to extend the pipeline, you can use the exported classes and push in your own compiler like this:

or this:

I hope this inspires someone, for me it feels like a good approach when implementing timbrandin:sideburns@0.3.0 because now you can pass through content to the next one in the pipeline like this (and we don’t have to create a new filename extension).

TemplatePipelineCompiler.push(class Compiler {
  processFilesForTarget(inputFiles) {
    inputFiles.forEach(function (inputFile) {
      let source = inputFile.getContentsAsString();
      let content = source.replace("</template>", "Hello world</template>");


Hey guys, how do we make our project use a release permanently so we don’t have to type or alias meteor --release PLUGINS-PREVIEW@2?


meteor update --release PLUGINS-PREVIEW@2


Is it possible to tell if an InputFile is a file that has been modified (i.e. is a file that triggered a call to my compiler.processFilesForTarget method)? EDIT: nevermind, I see getSourceHash.

What if there was a boolean property like inputFile._resourceSlot.inputResource.modified that specified if an input file was modified (i.e. the file that triggered a rebuild)? It might be useful when this is implemented: That might be more convenient than comparing hashes for some compilers.