deprecate requires option

[silkentrance]

With rechoir in place, the requires option is no longer required.

[tkellen]

The requires option can be used for more than pre-loading js-variant interpreters.

[silkentrance]

With rechoir in place, the requires option should no longer be used to load pre-load js-variant compilers/transpilers.

[phated]

Rechoir isn't in place, as noted in https://github.com/tkellen/node-rechoir/issues/17

Allowing people to require anything will allow them to pre-load transpilers if they choose. There is no way to restrict that.

[silkentrance]

@phated Why isn't rechoir in place? This seems to be a issue to me, liftoff not being able to reuse the node-interpret registry nor node-rechoir, altogether reimplementing the same behaviour.

And, as it seems, with liftoff being incorporated into my favorite tool (grunt), this seems to be a major drawback for me as I will never be able to get what I want :dancer: , namely support for arbitrary dialects without the need of a global registry in form of node-interpret.

[phated]

@silkentrance what are you talking about? Liftoff already uses interpret. rechoir added new functionality for legacy module support which hasn't been backported to liftoff. As mentioned in the linked issue, having specific functionality in rechoir for a very liftoff-specific feature is undesirable.

[silkentrance]

@phated having synchronized my clone with the current master, there is no dependency towards node-interpret whatsoever. I do not know what you are talking about.

[phated]

@silkentrance I think you need to investigate how all of these libraries work together. You can see how they are used at https://github.com/gulpjs/gulp/blob/master/bin/gulp.js#L21-L26

[silkentrance]

@phated you are not abstracting away the whole problem. The extensions option is actually obsolete, or, rather not so obsolete as @tkellen put it, as there are file extensions that are specific to a given tool but which will map to an existing extension that in turn can be mapped to a compiler/transpiler/interpreter instead.

Hence my request for supporting arbitrary dialects in node-rechoir.

You are making this API depending on the (limited) requirements of gulp instead of making it universal as it was your original intent.

[phated]

@silkentrance those tools give their own objects as extension -> transpiler objects and don't use interpret. You are conflating too many things and are actually trying to make liftoff less flexible. In no way should liftoff have a hard dependency on interpret. The only way it will have a dependency on interpret is if we want to use it as a default for extensions (which we probably won't).

[silkentrance]

@phated Heck, how difficult can it be, having node-interpret and node-rechoir in place, why would one to reimplement the existing behaviour instead of build on top of it, layer wise... And in no way I would liftoff to be less flexible, as it is already inflexible as per your provided example, which limits the configuration files to just the available js dialects extensions registered with node-interpret?

[phated]

Dude, you are seriously confused. I can't continue this discussion if you don't understand how the code works.

[silkentrance]

@phated

There is no discussion here, my point is correct and yours is ultimately wrong and I may prove it, wait for my PR to liftoff, and, since gulp depends on it, to gulp as well.

[tkellen]

Every single invocation of every single tool that uses Liftoff does not need the complexity of your extremely narrow use case. You can have what you want right now: fork + npm link = done. Once you've stabilized your in-development language, you can add it to interpret and it'll be published in a matter of hours.

[silkentrance]

@tkellen this is not about me, it is about everyone that wants to implement a new dialect or alias an existing extension to another, different extension, for example multigulpfile.multigulp or something like that. (in terms of gulp and its behaviour towards limiting the available extensions to the already registered js dialects.) And multigulp is just an example here, don't take it too literally. Something which the current implementation will not support. And the complexity is near to zero when using appropriate file filters.

[tkellen]

Find me 10 people with this problem and I'll re-consider adding this feature. As it is you can get support for this in a liftoff cli-powered tool with tool --require mylang --configfile myconfig.whatever

[silkentrance]

Yes, you are right, I would not be able to find 10 users...

Since this is terminal, I am willingly ignoring that request and simply continue with my original request, if you will.

Perhaps the rather simple changes I will propose in my PR will make you think otherwise and help to improve on the reuse of node-rechoir.

[tkellen]

--require is not going to be obsoleted.

[silkentrance]

it will be blatantly ignored instead :grinning: and leaving it to rechoir to figure things out? or should this be used in conjunction with resolving the config file and its extension, both registering with node-interpret and then calling upon node-rechoir to sort things out? this would be the way to go, i presume.

e.g.

configfile = findup.findFile configfileregex // if there were such an api
interpret.extensions[configfileextension] = requiremodule
... = rechoir.requireFor configfile

[tkellen]

The use case for --require in liftoff is orthogonal to the problem being solved by rechoir. On Feb 14, 2015 6:09 PM, "Carsten Klein" notifications@github.com wrote:

it will be blatantly ignored instead [image: :grinning:] and leaving it to rechoir to figure things out?

— Reply to this email directly or view it on GitHub https://github.com/tkellen/node-liftoff/issues/37#issuecomment-74396042.

[silkentrance]

Actually --require becomes obsolete once rechoir is being used by liftoff. And I do not see any use case other than what I proposed in my now prematurely closed PR over at node-rechoir which would enable users to add arbitrary aliases for existing jsVariants a/o extensions...