Overriding of require paths and templates

[janhancic]

BRJS should support some sort of override mechanism for require paths, HTML templates, and other stuff. How exactly this would work needs to be figured out, but what I want as a feature is:

Have some sort of config, where I can say app/something/Foo -> app/custom/something/Foo. Which would mean, that wherever app/something/Foo is required, BRJS would actually return app/custom/something/Foo. Same goes for HTML templates, XML stuff, etc.

The HTML/XML bit could be done entirely client side, but I would prefer a unified solution.

There are several reasons for doing this. One major PITA is when people take our apps and customize them. This ties our hands behind our back as it's hard for us to then make changes. And it's also hard for people to customize our apps, as they have to deal wit merges on every upgrade.

Let's have a discussion about this next week.

[andy-berry-dev]

@janhancic How does this differ from aliases and is it something that could be tied in with the existing alias mechanism?

This ties our hands behind our back as it's hard for us to then make changes. And it's also hard for people to customize our apps, as they have to deal wit merges on every upgrade.

If customers started using a different class by overriding the require path they wouldn't then get upgrades to that class. They would potentially then take upgrades to other libraries which would then break since they depend on changes that haven't been made, or they would have to merge the changes from the original class into their overridden version which sounds more painful than what they would currently do.

Unless I'm missing something I don't think this is a solution to help upgrade pain, but it is something I can see being useful - even if its an extension & clean up of the existing aliasing mechanism to make it easier to use for developers new to BRJS/CT.

[janhancic]

The difference between this and existing aliases is that developers don't have to actually create aliases in order for something to be overridden.

There are risks with what you said. But I think it's still better than what we have now. As long as customers conform to the same interface they should be fine. And yes, if we upgrade the class they based their work off from, they will have to do a merge. But they have to do that now already.

I think @james-shaw-turner should get involved with this. I already introduced this idea to @dchambers and he said he sees it as useful. But let's organise a meeting or something and discuss this further.

[andy-berry-dev]

The difference between this and existing aliases is that developers don't have to actually create aliases in order for something to be overridden.

I can see that being useful. Is there any reason why aliases can't work in this way? I don't see this as a different feature to aliases, but an extension to them. If any require path, whether or not it exists, can be overridden then we have the flexibility to satisfy both use cases. Groups could still then be used to change the configuration for 'dev', 'test' and 'prod' in order to use stub services etc.

[janhancic]

I don't understand what you mean. Can you give an example to show how you see this working?

[dchambers]

The require.js library provides a number of features like this. It's paths config can be used to point to re-point a path, or even to specify a fall-back, and it's maps config can be used to cause different paths to be used depending on who's asking the question.

Our aliasing mechanism pre-dates our adoption of CommonJS (and it's require() method), which we almost certainly wouldn't have been needed if we'd moved to CommonJS first.

[dchambers]

OTOH, I think our motivation for doing this is probably based on anti-pattern — treating view-model code as a supportable library — and although path patching may help us continue down that road in the short term, it's just as likely to make things even worse in the long run. Just a thought...

[adamshone]

I don't think this is to do with view-model code or supportability, it's just a basic problem to do with unit testing modules. If you've got a module like this:

var webService = require('/br/webservice');

function Foo() {
   webService.doSomethingExpensive();
}

module.exports = Foo;

We currently have no way to swap out webService with a mock, for unit testing.

Couple of approaches used by other libraries/frameworks that we can use for inspiration:

Rewire adds a setter that can operate on private members:

var rewire = require("rewire");
var Foo = rewire("/Foo");

var mockWebService = ...
Foo .__set__("/br/webservice", mockWebService);

new Foo();

Webpack has an inject-loader:

var mockWebService = ...
MyModuleInjector = require('inject!/Foo);
Foo = MyModuleInjector({
  'br/webservice': mockWebService
});

new Foo();

[janhancic]

There is a way to do that in tests, with subrealms. And this isn't about tests really.

Anyway, if you want to see how you can do that give me a shout :)

[dchambers]

It looks like this feature is going to be necessary for BRJS 1.2 since we're going to need mappings like:

• br/libX -> @brjs/libX
• caplin/libX ->@caplin/libX

It's important that the mappings can be defined centrally (or by each library), so that when we migrate a library to NPM we can also include the config changes for any new mappings.