Allow users to provide a custom node-interpret.js module for adhoc extension of the supported languages

[silkentrance]

For starters, and as a follow up to the discussion we had about making this more versatile over at gulpjs/interpret#12, I'd like to propose that

• users can provide their own 'interpret-custom' module, that when available, will be mixed into the existing interpret registry
• here, users can provide their own extension to registration module mappings

Upon load, node-rechoir will by require its own interpret module. In addition to that, it will also look for a interpret-custom and try to require that as well. When available, it will merge in the mappings found in interpret-custom into those from the standard interpret, overwriting existing or adding new mappings.

In order to prevent encouraging users from publishing a node-interpret-custom or interpret-custom package to NPM, node-rechoir will look in the following locations

• package-root/interpret-custom.js
• package-root/src/interpret-custom.js
• package-root/lib/interpret-custom.js

It will not use standard node package/module resolving, so placing this under node_modules will have no effect.

The package-root is assumed to be equal to the cwd variable, or, if that is missing, it will be determined from the resolved absolute path of the specified filepath, looking for either package.* or 'src' or 'lib', or 'node_modules'.

[tkellen]

I'm not wild about supporting tons of different locations. What do you think about using findup-sync to look for .interpret.js from cwd, all the way up the directory tree?

[silkentrance]

findup-sync it is, then.

As for the name, should it really be a hidden file?

[tkellen]

I guess it doesn't have to be--I'm open to whatever as long as there is only one case-insensitive name.

[silkentrance]

Then I'd be happy to make this a non hidden file and name it node-interpret.js, if you so please. The rationale for this would be that the name 'interpret' is a rather common one for packages that for example implement an interpreter.

[tkellen]

works for me!

[silkentrance]

PR #9 now available. Please have a look.

[phated]

After thinking about this, why can't rechoir.interpret just be mutated for development of new languages?

[silkentrance]

Because this would prevent me from for example using grunt with a different language than those listed in interpret.

That is, running grunt test will only work for languages already known to liftoff/rechoir/interpret.

In turn, I would have to write a grunt task or manipulate the data structure in node-interpret directly
and differently for each tool I would want to use languages with that are not going to be supported by rechoir/interpret because they are simply personal experiments or work in progress with the initial release far in the future.

And, of course, I would not be able to author my Gruntfile in that language in the first place unless, again, I fall back to --require or other parameters each tool might provide for such cases.

So, instead of having to instrument each tool, I'd rather just copy the node-interpret.js for that language into whatever project I am using it with, add the necessary dependencies to my package.json and off I go, never having to instrumentalize the Gruntfile or whatever configuration the tools I am using use.

And I am also able to do this on a per directory/sub package basis, see test/custom_interpret/inherit and .../override. Something I would not be able to do in a not-a-pain-in-the-a way when having to manually mutate the interpret data structures.

Leaving me with the last part, where a given tool cannot be configured in such a way but makes use of rechoir/interpret. Here, I would be stuck with extending the tool, which is something I would not want to do, maintain my own clones of these tools.

[phated]

Can this be solved through an rc file? I think they are under consideration in liftoff gulpjs/liftoff#8

[silkentrance]

The rc file is part of the application and gets parsed by that application.

The use case I have in mind not only includes apps that use liftoff for setting up their environment, but rather libraries that make use of rechoir independently from liftoff.

Consider a server application that allows views to be written in arbitrary languages. While the server application is based on for example express, loading of the views should be automatically done by on-the-fly registration of required compilers/transpilers/loaders. The view/template loader of the application would then simply registerFor(templatePath) and optional node-interpret.js files would then ensure that the interpret configuration is updated accordingly.

And it would be nice to reuse rechoir/interpret for that purpose as well.

Another use case are multiple tools in use for for example the build process. Having grunt, mocha/vows and other processes all requiring different configurations for the very same thing is rather tedious and leads to unnecessary maintenance overhead.

[silkentrance]

Could this be merged to master or are there any objections to this? Provided, of course, that the documentation is updated appropriately.

[phated]

I don't think this should be added. It is easy enough to mutate the interpret object to include new languages during development/testing. Interpret/rechoir have multiple maintainers now and we should be super quick to merge any new languages added. @tkellen thoughts?

[tkellen]

Agreed. I'm very sorry @silkentrance, but I don't see the value in adding this complexity to every invocation of rechoir. As @phated said, you can require and mutate the interpret object very easily. You can also just add any language you want to interpret.

[silkentrance]

Super quick does not mean that we would be willing to include every language experiment that exists.
For language experiments we should still be able to provide users with a simple means of adding that experiment to all of their projects without necessitating them to modify the 'internal' structures of node-interpret. Simply copying a javascript file to their precious test/sources should do the trick, not instrumenting their gruntfile/gulpfile nor their test cases.

[phated]

Not sure what you mean by "nor their test cases", liftoff will continue to support --require which allows people to load any custom module, including language extensions.

[silkentrance]

Sigh --requires is actually obsolete with node-rechoir in place. Reuse, anyone?