Closed danielkcz closed 7 years ago
Good PR! I'd merge if the stamp was a separate @stamp/auto-configure
package.
About preventing double import:
privatize
(or any other stamp) goes very popular I'd consider embedding it to @stamp/it
(that's the reason why @stamp/it
is actually different to stampit
)Ok nevermind, it was just an idea, I am not feeling for doing it as a separate package. Considering it is a two liner and with the separate package, I would need another two lines (and installation) to actually use it, it's not really worth it.
Btw, you have there privatizeMethod
, so having privatizeConfig(prefix = 'stamp')
the same way could be easily seen as a part of the package and not really like something extra because I said before it doesn't really make sense to expose config like this without privatizing it.
Sounds like an idea. I'll think about it.
On Sun, 23 Apr 2017, 16:20 Daniel K. notifications@github.com wrote:
Btw, you have there privatizeMethod, so having privatizeConfig(prefix = 'stamp') the same way could be easily seen as a part of the package and not really like something extra.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stampit-org/stamp/pull/22#issuecomment-296422571, or mute the thread https://github.com/notifications/unsubscribe-auth/ABjCL4npe21RKE2Q5HNLGZsMZ0C2b36Pks5ryu2egaJpZM4NFJE2 .
It's very trivial and doesn't make much sense for regular stamps. However, with Privatize it's perfectly sane to do this since it will disappear from replaced instanced.
Thinking if it would actually good idea to incorporate it as optional part of Privatize stamp to avoid double import. Something like
compose(Privatize.withConfigure())
. Or simple static property to allowimport Privatize, { Configure } from '@stamp/privatize'
. What do you think @koresar ?