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

slava · July 30, 2015, 5:49pm

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

trusktr · August 1, 2015, 6:55pm

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

trusktr · August 4, 2015, 11:19pm

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

timbrandin · August 9, 2015, 5:17pm

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.

timbrandin · August 9, 2015, 11:32pm

You should check out https://atmospherejs.com/pipeline, 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: https://github.com/meteor/meteor/releases/tag/release%2FANUBHAV-ERROR-APP-TEST%401

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:

github.com

MeteorPipeline/templating/blob/master/plugin/plugin.js

// The CompileResult type for this CachingCompiler is the return value of
// htmlScanner.scan: a {js, head, body, bodyAttrs} object.
TemplatePipelineCompiler.add('CachingHtmlCompiler', new CachingHtmlCompiler(
  "templating",
  TemplatingTools.scanHtmlForTags,
  TemplatingTools.compileTagsWithSpacebars
));

or this:

github.com

MeteorPipeline/ecmascript/blob/master/plugin/plugin.js

class BabelCompiler {
  processFilesForTarget(inputFiles) {
    inputFiles.forEach(function (inputFile) {
      var source = inputFile.getContentsAsString();
      var inputFilePath = inputFile.getPathInPackage();
      var outputFilePath = inputFile.getPathInPackage();
      var fileOptions = inputFile.getFileOptions();
      var toBeAdded = {
        sourcePath: inputFilePath,
        path: outputFilePath,
        data: source,
        hash: inputFile.getSourceHash(),
        sourceMap: null,
        bare: !! fileOptions.bare
      };

      if (fileOptions.transpile !== false) {
        var babelOptions = Babel.getDefaultOptions();

        babelOptions.sourceMap = true;

This file has been truncated. show original

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>");
      inputFile.setContentsAsString(content);
    }
  }
});

trusktr · August 17, 2015, 5:05am

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?

glasser · August 17, 2015, 7:11am

meteor update --release PLUGINS-PREVIEW@2

trusktr · August 29, 2015, 1:15pm

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: https://github.com/meteor/meteor/issues/4899. That might be more convenient than comparing hashes for some compilers.