luma v9.0.0 alpha.5

[ibgreen]

For #7457

Background

Change List

[ibgreen]

@Pessimistress Having problems even starting tests... Can you verify if

• node tests can run (start)?
• browser tests can run (start)?
• development can be done on Node 16? Node 14 installs seems to have issues with M1 Macs.

[ibgreen]

Also, JS build log shows lots of type issues that don't show up in luma.gl - wonder if there are different typescript settings that trigger it but haven't found it.

[ibgreen]

Also, JS build log shows lots of type issues that don't show up in luma.gl - wonder if there are different typescript settings that trigger it but haven't found it.

The reason seems to be that deck.gl sets "strict: true" in tsconfig.json. Doing the same in luma.gl generates about 600 errors. I can start fixing them there while we disable strict here temporarily.

[felixpalmer]

I've pulled this branch and tried running the tests. I'm on a M1 Mac and using node 14.18.1 (installed using nvm without issues). The tests (yarn test fast) are not running for me, with the following error:

Running node tests...
deck.gl/node_modules/@luma.gl/test-utils/dist/index.js:1
export { default as SnapshotTestRunner } from './snapshot-test-runner';
^^^^^^

SyntaxError: Unexpected token 'export'

Comparing node_modules/@luma.gl/test-utils/package.json between v8 & v9, in v9 both the main and module entries point at dist/index.js (an ESM module) while in v8 main points to dist/es5/index.js

[ibgreen]

OK. I can certainly see us vigorously debating the merits and disadvantages of ESM modules, but trying to dodge that question for a moment to avoid a complete overload of required changes on the luma side.

It was a while ago, but as far as I recall this was not an issue when I did a test integration six months back. It could be that recent changes in node.js tooling on the deck.gl side now makes deck requires a more heavily transpiled build?

It does seem that yarn test browser does not break on the exports, however I get a crash on the PipelineFactory there. That seems debuggable. Maybe we can start with browser tests?

[ibgreen]

run test browser gets through over a thousand tests before failing, but then there are a lot of failures seemingly related to hook injections.

It would be good to get some debug help with this as I find this system a bit tricky to follow. I did overhaul the luma.gl shadertools module in multiple passes to add strict types, so it is possible that I have introduced a bug on the luma side, though the shader injection tests do pass.

Looks like the hooks are "declared" globally here: https://github.com/visgl/deck.gl/blob/luma-v9.0.0-alpha.5/modules/core/src/shaderlib/index.ts#L44. But somehow actual values for those hooks fail to inject.

It could help to understand how these hook definitions are supplied and how they flow through to the final shader. Through the shader modules that a shader picks?

@felixpalmer @Pessimistress

[ibgreen]

I am also not able to change test files to typescript, is that intentional?

/Users/ibgreen/code/deck.gl/test/modules/core/effects/lighting-effect.spec.ts
  0:0  error  Parsing error: "parserOptions.project" has been set for @typescript-eslint/parser.
The file does not match your project config: test/modules/core/effects/lighting-effect.spec.ts.
The file must be included in at least one of the projects provided

[ibgreen]

Created v9 trackerL #7457.

Some of these tasks are very generic and could be done in parallel.

[ibgreen]

Some automated formatter is stripping out types casts. Those cases were probably added to make strict mode work, and perhaps they are being stripped now that I disable strict mode. On the other hand those casts and exclamation marks are potentially hiding problems.

[ibgreen]

Looks like some examples might be starting to work. Landing as baseline.