Damien Seguin

Separately bundling with `target: webworker` does work but produces bigger files and put the Workers outside webpack module resolution logic. I'd still like to be able to use the more...

> We should keep them, it is bug if we remove them Nevermind, they are preserved, no problem > I don't think we should add new semantic to JS, it...

In an ideal world, the Worker script I am importing should be valid either as classic or module worker. But because of the complexity of bundling workers in the JavaScript...

@prescottprue is there any workaround this? My use-case is that I am using `useFirestoreConnect({ collection: "todos", storeAs: "todo", doc: docId })` and I'd like to be able to clear `state.firestore.data.todo`...

I'd be interested in this feature too 👍

`WEBGL_lose_context.loseContext` is hard to reason about because implementations varies. I'd keep it in user land.

Do you prefer getters or function return? Eg.: ```js Object.assign(ctx, { ...rest get width() { return gl.drawingBufferWidth }, // or width: function() { return gl.drawingBufferWidth }, }) ctx.width() // or...

@vorg Updated the PR

For webpack users, a temporary workaround might be to disable the `resolve.fullySpecified` rule: https://webpack.js.org/configuration/module/#resolvefullyspecified

I exposed the `getMaxPrecision` as the user needs it when overriding a material with a certain precision. See: - material override on init: https://github.com/pex-gl/pex-renderer/pull/125/files#diff-e05576c1b4de3bdf09150674b923ae50R39 - getMaterialProgramAndFlags: https://github.com/pex-gl/pex-renderer/pull/125/files#diff-168726dbe96b3ce427e7fedce31bb0bcR208 I agree it...