You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the register() method keeps whatever was registered in memory, but if two libs were using filing-cabinet at the same time, they may have differing requirements for custom resolvers. maybe a resolver for .foo is different from one to the other, or perhaps one of them should not, under any circumstances, resolve a .foo file.
a way to address this would be to provide a factory function, e.g.:
constfilingCabinet=require('filing-cabinet');constcabinet=filingCabinet.create();cabinet.register('.foo',myFooResolver);cabinet({partial: 'bar',filename: 'quux.js',directory: '/some/path'})// works with .foo filesfilingCabinet({partial: 'bar',filename: 'quux.js',directory: '/some/path'})// does not work with .foo files
I can send a PR to that effect, or if you have a different idea...
The text was updated successfully, but these errors were encountered:
Thanks for the issue! Man, I'm back and forth on this.
So create would return an instance of some inner constructor with its own default lookups?
I think the simpler approach involves changing the module to export a constructor and force you to create instances, but that's a breaking change.
Supporting the dual mode of the default export being just a function call with the tradeoffs you outlined, with the ability to build a new instance for local scoping of state, isn't the end of the world.
If you want to put up a draft for us to review, I'd be happy to take a look and see what the implementation would become.
If you think the breaking interface change of exporting a constructor would be better off, I'm open to that too (should have likely done it that way from the start).
the
register()
method keeps whatever was registered in memory, but if two libs were usingfiling-cabinet
at the same time, they may have differing requirements for custom resolvers. maybe a resolver for.foo
is different from one to the other, or perhaps one of them should not, under any circumstances, resolve a.foo
file.a way to address this would be to provide a factory function, e.g.:
I can send a PR to that effect, or if you have a different idea...
The text was updated successfully, but these errors were encountered: