Use module.watch(require(id), ...) to avoid calling module.require.

[benjamn]

If we choose to go in this direction, we would be removing a significant barrier to interop with CommonJS module systems other than Node (in particular, Webpack and Browserify), since module.require would no longer be a requirement, and third-party bundling tools could easily understand dependencies embedded in module.watch(require(id), ...) calls.

I'm not committed to module.watch as a method name, though it's short and accurately reflects that the parent module is watching an exports object returned by a child module.

[benjamn]

A really interesting question is whether a package that uses a version of Reify that generates module.importSync calls could work alongside a package that generates module.watch calls. I think probably yes, but it would be nice to verify.

[jdalton]

this.watch(this.require(id), setters, key)

[jdalton]

Would this deprecate importSync, with the plan of removing it in a near future version?

[jdalton]

Heads up: I rebased this PR.

After this is merged it may be a good time to revisit the problem of referencing module and require in the generated code (since user code could redefine them). I'm cool just creating unique-ish vars and using them. By creating unique-ish vars I'm mean something as simple as __reifyModule and __reifyRequire 😋

[benjamn]

Would this deprecate importSync, with the plan of removing it in a near future version?

Yes, I think importSync will be unnecessary in the future, and we should remove it, though I vaguely worry about breaking existing generated code by changing the runtime.

[jdalton]

Cool. We could deprecate it in v0.11 and remove it in v0.12 (that's being super nice)

[benjamn]

Do you have any preferred techniques for giving not-too-noisy deprecation warnings?

[jdalton]

I'd put it in the readme for v0.11 and you can add a note on npm install with npm deprecate just for v0.11.

[jdalton]

Should the "require(" + getSourceString(this, decl) + ")" bit be in either the first pad() or the following one?

[benjamn]

Good catch, I think it should go in the one above, since it's usually (always?) only one line, and that line is the first line of the module.watch expression.

[benjamn]

Fixed, thanks!

[benjamn]

After this is merged it may be a good time to revisit the problem of referencing module and require in the generated code (since user code could redefine them). I'm cool just creating unique-ish vars and using them. By creating unique-ish vars I'm mean something as simple as __reifyModule and __reifyRequire 😋

I definitely agree we should do that for module. I think require is much safer, though, since most people know they'll mess up their Webpack bundles if they rename/shadow the require function. Also, we want bundlers to understand our usage of the require function, and module.watch(__reifyRequire("source"), ...) would be just as confusing as module.importSync("source", ...).

[benjamn]

• Note to self: update the README.md to reflect these changes. 2c78577