Source handler doesn't run for a file extension if it is a file name

[stevezhu]

When using a file name as a file extension when registering a source handler as cited in the Plugin.registerSourceHandler docs

Plugin.registerSourceHandler('some_json.json', function(compileStep) {
  console.log('In some_json.json source handler');
});

"In some_json.json source handler" isn't logged unless you also add a source handler with just json

Plugin.registerSourceHandler('json', function(compileStep) {
  console.log('In json source handler');
});

Note: this works fine for api.addFiles in packages

reproduction: https://github.com/stevezhu/meteor-source-handler-bug
using osx mavericks 10.9.5 if it's relevant

[glasser]

So, you're right that there's a bug here, but the bug is that the exact filename match ever works at all. The feature is documented as:

The file extension that this plugin should handle, without the first dot. Examples: "coffee", "coffee.md".

It's pretty explicit that this is supposed to be an extension, and most of the code (eg, the code that looks for relevant files inside an app) correctly handles this. The fact that, in certain odd cases, the full filename can match, is a bug that I'll fix. Thanks!

[avital]

I think some packages may have depended on this behavior. (Unfortunately I don't recall specific examples)

[glasser]

@avital Would love to know. I checked https://atmospherejs.com/mizzao/build-fetcher and it uses extension.

And note that the behavior worked inconsistently here: it would work in a package, or in an app if there was a suffix of the extension also declared (as @stevezhu showed). Because the code that looks in your app for files to process does assume that extensions are extensions:

        var sourceInclude = _.map(
          extensions,
          function (isTemplate, ext) {
            return new RegExp('\\.' + utils.quotemeta(ext) + '$');
          }
        );

[stevezhu]

Ahh I see, thanks for that clarification and glad I unintentionally uncovered another bug.

[johanholmerin]

mquandalle:bower and numtel:publicsources both rely on this.

[glasser]

@mquandalle @numtel You may way to try to address this before the next Meteor release.

(I'm thinking of adding filename: support to a build plugin refactoring though.)

[johanholmerin]

@Differential's Vulcanize also uses this pattern.

[numtel]

@glasser Already taken care of. My packages are no longer dependent on this bug.

[avital]

https://github.com/elidoran/cosmos-browserify also depends on this, or at least the example in the README (cc @elidoran)

[elidoran]

Good to know, thank you @avital
I'll revise cosmos:browserify accordingly.

EDIT: revised and published. thank you.

[glasser]

Note that a forthcoming version of Meteor (implemented on the batch-plugins branch) allows plugins using the new registerCompiler API to register for specific filenames in addition to extensions.