mrmaxm

It's probably either that or: `@param {('rect'|'circle'|'ellipse')}` - which is what you try to avoid with constants in the first place?

> I think this is a clear area where TypeScript really delivers on something JavaScript struggles with. It is more IDE issue rather than language issue. TS - helps as...

> But at the same time, it isn’t only an IDE issue. TypeScript’s language-level features and compiler checks add an extra layer of safety and consistency that JSDoc alone can’t...

I believe enums should differentiate from Classes (PascalCase), as we have exclusively been using PascalCase for classes only. This helps readability and to know what is what. For object properties,...

> Just checked Babylon. They [do 2](https://doc.babylonjs.com/typedoc/enums/BABYLON.Aggregations). One of the key reasons for this is because it's a TypeScript coding convention and Babylon is, of course, written in TS. Just...

There is some benefit of exposing it, and allowing this to be configured. As number of parsers are likely to only grow. It will allow some code stripping.

I agree that cast/receive shadows should be on primitive as they are an individual draw calls, and have own shadow/shader/render states. Also, what are the default values? For consistent rendering...

> Assigning to materials, rather than primitives, might also solve that issue? Similar to material.doubleSided=true. Although then casting and receiving properties might end up in different locations.. I'm afraid this...

> Thanks for the feedbacks. They make sense to me. I moved the extension from under `mesh` to under `mesh.primitive`. > > Regarding `mesh.primitive` vs `material`, please let me know...

I would definitely avoid using eval as much as possible. E.g.: post a link in forum/git, asking: "I have a bug, here is repro", users will follow it, and end...