allow Library.require override

[mbostock]

This PR allows the user to change the require implementation by assigning to Library.require.

Originally, I intended this to be local to the Library instance (hence the resolve argument to the Library constructor). However, there are a number of places where we want to require stuff statically, such as within the AbstractFile class definition. Therefore it seems unavoidable to have only a single definition of require. (Eventually we want to move everything to dynamic ES module imports anyway…)

[duaneatat]

Does this create the possibility of a race-condition if there are in-flight requires when setDefaultRequire is called?

[mbostock]

Does this create the possibility of a race-condition if there are in-flight requires when setDefaultRequire is called?

You can’t really have multiple requires at the same time (because require is built around a single global function named define), so the expectation is that you set Library.require before you do anything else.

[duaneatat]

You can’t really have multiple requires at the same time (because require is built around a single global function named define)

Yep, that limitation is the reason I asked -- the race-condition I was referring to is if the user changed require while there are in-flight requires, since both requires depend on the global define. But I acknowledge that this is a pretty contrived scenario so this lgtm!

[mbostock]

This was totally broken… sorry for not testing before asking you to review. I fixed this in 6de65c3. It’d be nice to have a better way to test this locally via unit tests.

[mbostock]

Also I needed to re-export requireFrom and resolveFrom in 784dcb3 so I could use them (without having to load d3-require twice, since d3-require is baked-in to this library).