Unlock gl-shader

[dy]

Resolves gl-vis/gl-mesh3d#12, gl-vis/gl-error3d#4, gl-vis/gl-axes3d#11 and yarn bundling mentioned by @nicolaskruchten

[dy]

@alexcjohnson could you please have a look :)

[dy]

@nicolaskruchten can you please try bundling w/yarn the git@github.com:plotly/plotly.js.git#7b1bb6a5aa9fae0d4d05420f7ae81798f4fc5ef8? That should fix the issue.

[alexcjohnson]

why are we adding a package but making no direct reference to it?

[dy]

@alexcjohnson good point. I wonder if we should remove gl-shader dependency as well, since we're not using it by plotly directly. @etpinard had it fixed version at the root level to ensure that all components use the same gl-shader. But that is no more relevant since now on.

[alexcjohnson]

Sounds reasonable to me, but after the mess we had yesterday with npm ls I'd like to figure this out with @etpinard 's input.

[alexcjohnson]

💃 from my side, but I'd like to hear from @nicolaskruchten whether this accomplished the goal.

[nicolaskruchten]

💃 from me, I tested all permutations of installer=(yarn, npm) and bundler=(browserify, webpack) and the WebGL bug doesn't appear :)

[etpinard]

This PR seems to have made the tests fail on master

https://circleci.com/gh/plotly/plotly.js/6120

[etpinard]

Re-running the tests on master w/o cache (i.e. with a brand new node_modules/ folder) helps a little bit:

https://circleci.com/gh/plotly/plotly.js/6129

Only 3 surface mocks are failing:

[etpinard]

After re-running the tests w/o cache off this PR's last commit 0d1d19b, the same surface mocks are failing.

https://circleci.com/gh/plotly/plotly.js/6130?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

This is good news. At least we have some sort of consistency.

[dy]

@etpinard added baselines 8456f95, seems there is very subtle shading or dithering difference, as if color conversion is a bit wrong. I'll try to reproduce that.

[dy]

@etpinard tbh that is pretty mystical difference. That is not even clear if the behavior before was correct. That seems like internal WebGL thing − as if order of binding affects attribute/uniform precision here or in a place like that.