Closed jcwilson closed 7 years ago
This is incredibly interesting and bizarre. I won't be able to look into it until the end of next week at the earliest though, not sure if @mattrheault has some time to take a look.
I don't think the webpack version has been updated in a while so perhaps the easiest first thing to try is seeing if this still reproducible moving to the newest version of webpack
I can't rule out that it's something specific to my setup, somehow. Unfortunately, I just have my one data point.
For reference, though: node version: 6.10.0 npm version: 3.10.10
I think I can explain what's happening, though I don't have a good answer for fixing it yet.
First, upgrading webpack didn't resolve it, but I don't think it hurt anything.
I noticed that in the Namespace
module, we have the following import:
import { Sample, RandomInteger } from "./ops/random.js";
This will essentially "freeze" the non-core-compatible code into the Namespace
module. In fact, this pattern is repeated in several other places, even ops/utils.js
. When I first encountered this behavior I was confused because my experiments seemed to be operating in core-compatibility mode. But now this explains it - the random part is instantiated and passed in as part of the experiment definition (in assign()
). And as I noted above, we get the compatible code if we reference planout.Ops.Random
directly.
assign: function(params, args) {
params.set('foo', new planout.Ops.Random.UniformChoice({choices: ['a', 'b'], 'unit': args.userId}));
}
I have updated the repro code above to reflect these new learnings.
EDIT: Upon closer inspection, the Experiment
and Assignment
modules are largely unaffected by this anyway, as the only reason they need random
is to get PlanOutOpRandom
to do some type checking against it - and the core-compatible ops inherit from it anyway. Still, the analysis above still stands up.
Hope this helps.
Fixed in v.4.0.0 release.
Problem
The
planout_core_compatible.js
distribution in 3.0.* does not allocate namespace segments in a compatible manner.I have done a little digging into the webpack'd distribution, but I'm at a loss to explain the root cause. The best I can tell is that when
SampleBuilder.sample()
callsthis.compatSampleIndexCalculation()
it gets routed toSampleBuilder.compatSampleIndexCalculation
which is the non-compatible version, rather than toSampleCoreCompatible.compatSampleIndexCalculation
.As far as I can tell, the compatible random ops are working as expected when called directly. Perhaps it's a bug in webpack?
Reproduction Case
Output
Notice the last two lines. They should match, but do not.
I considered that it might be due to loading all three versions into one script, but the results are consistent if I just run one version's tests at a time.