Export BufferTransform from luma.gl

[zakjan]

Background

#8574 in v9 limited luma.gl exports only to a few selected classes. There is a removed TODO "Cherry-pick luma core exports that are relevant to deck". Following this reasoning, can we export BufferTransform as well? It's used in GPUInterpolationTransition.

My need for it is driven by a custom layer in a pure-JS environment, where deck.gl is imported with a script tag. As parts of luma.gl are still exported, it seems this case is still supported. Otherwise it would be necessary to import a full luma.gl bundle with a matching version.

Change List

• Export BufferTransform from luma.gl

[coveralls]

coverage: 89.987%. remained the same
when pulling ff4bde4 on zakjan:zakjan/export-buffertransform
into a16c706 on visgl:master.

[Pessimistress]

I don't have a strong objection against this particular request, however, the pre-built bundle is not really designed for complex applications. If you need something else from luma that is not actively used in core, I would say no, because we want to prioritize bundle size over niche advanced use cases.

Also just FYI BufferTransform is marked as @deprecated and will likely undergo major refactor in the near future.

[zakjan]

@Pessimistress Thanks, I wouldn't suggest increasing the bundle size if it were anything else not used by deck.gl itself.

Possibly no luma.gl parts should be exported by deck.gl bundle after all?

Regarding using deck.gl and luma.gl bundles together, this works:

<script src="https://unpkg.com/deck.gl@9.0.3/dist.min.js"></script>
<script src="https://unpkg.com/@luma.gl/core@9.0.8/dist/dist.min.js"></script>
<script src="https://unpkg.com/@luma.gl/engine@9.0.8/dist/dist.min.js"></script>

Just there is a tricky part that version numbers inlined in the bundles are off-by-one. Both deck.gl 9.0.3 and luma.gl 9.0.8 bundles contain luma.gl version number 9.0.7, should be 9.0.8. This provides a misleading console log if a mismatching luma.gl version is used.

I suppose BufferTransform changes are aimed towards WebGPU compute shaders?

[Pessimistress]

Possibly no luma.gl parts should be exported by deck.gl bundle after all?

Since the conversation took us here, the luma exports are technically a necessity. deck/luma still uses x instanceof Buffer to check argument type, and this will break if there are multiple copies of luma core, even if they are of the same version. I'm mildly surprised that it works for you.

luma.gl 9.0.8 bundles contain luma.gl version number 9.0.7, should be 9.0.8

Thanks for flagging this, it should be a luma.gl bug.

[Pessimistress]

cc @ibgreen who advocates for exporting everything from core

[ibgreen]

cc @ibgreen who advocates for exporting everything from core.

Well, not quite.

• It was brought to my attention that one of the reasons for cherry-picking exports in the scripting setup was that @luma.gl/core was exporting helper functions that were only meant for other luma.gl modules.
• So I said: let me at least remove those exports before we make any other changes to luma.gl/core.
• I proceeded to remove these helpers in a series of PRs tracked in core module bundle size investigation luma.gl#2000
• Those changes are landed on master (i.e. 9.1)

Now, if the presence of these internal exports were the main reason for cherry-picking, then one option could be to "export everything from core". If there are other reasons, then perhaps not.

Finally, obviously, FWIW BufferTransform is not from core but from engine.

[zakjan]

Thanks for merging and fixing the bundled luma.gl version.

Now, if the presence of these internal exports were the main reason for cherry-picking, then one option could be to "export everything from core". If there are other reasons, then perhaps not.

As 9.1 is going to solve the concern with internal exports, it seems deck could return back to export everything as before #8574.

I understand the need to minimize the deck.gl bundle size, but it seems it went too far about this. Depends if there should be only a single deck.gl bundle with everything included or multiple smaller bundles with supported overlaps. In any case, somehow the entire luma.gl public API needs to be available.