It's useful for editors & data files to be able to enumerate constants. So instead of having "wrapS" : 1000 you can write "wrapS" : "RepeatWrapping", or if you want to construct a drop down for all the different texture filter modes etc. What seems to be the best approach at the moment is to copy & paste TEXTURE_FILTER, I think it would be better if they were just exported as is instead. Not only is it a whole lot cleaner than copy & paste, but it also guarantees that they're in sync if new ones ever gets added or if it's changed.
I'm not sure I understand. How should this exposition of constant values look like from your point of view?
Constants are exported as shown here: https://threejs.org/docs/#api/en/constants/Textures. I'm not sure I understand what you're suggesting as the alternative, sorry.
@Mugen87 @donmccurdy maybe what @Sairony means is, when you type texture.wrapS in the console, you get a number instead of readable string.
@Sairony you can do this, though:

Okay, I see. But I doubt we are going to change this. For example comparisons between strings tend to be slower than between numbers. With some user level code, it should be easy to get the intended mapping.
What I mean is that if lets say I want to be able to convert load a json entry such as "wrapS": "RepeatWrapping" into a proper wrapS to be set on a texture I need to map the string value to its numeric value first. To do this now I need to copy & paste all the different constants & create the mapping from string to value. But if they were already exposed I could do something like this:
let stringToConstant = Object.assign( {}, TEXTURE_MAPPING, TEXTURE_WRAPPING, TEXTURE_FILTER );
if( stringToConstant.hasOwnProperty( valueFromJSON ) )
return stringToConstant[ valueFromJSON ];
Or if in an editor I want to for example have a drop down to select texture filtering:
Object.keys( TEXTURE_FILTER ).forEach( x => dropDown.addEntry( x ) );
There's a lot of uses for being able to enumerate the different options for these. They're basically enums, it's kind of like the age old problem of converting enum entries to string & working with their mappings to their values in a lot of other languages.
TBH, I don't understand. The constant values are already exposed. What's missing?
I guess @Sairony is asking for all constants to be scoped under a particular namespace for their purpose. For example:
THREE.Mapping.UV
THREE.Mapping.CUBE_REFLECTION
THREE.Mapping.EQUIRECTANGULAR_REFLECTION
...
THREE.Wrapping.REPEAT
THREE.Wrapping.CLAMP_TO_EDGE
THREE.Wrapping.MIRRORED_REPEAT
From that perspective, the user can enumerate the choices in a dropdown with Object.keys(THREE.Wrapping) rather than having to maintain a matching list.
All else being equal I agree the scoped constants might be nice, but this seems like a major a hassle to change now, so I'm not sure we can justify moving all the constants.
Thanks for this clarification! Indeed, I don't think we make such a change. However, could the OP derive the desired information from the TS declaration file in some way? It seems, the structure for this is already there.
I guess @Sairony is asking for all constants to be scoped under a particular namespace for their purpose.
Related: #12579, #12972
In fact, this issue is a duplicate of #12579. Closing then.
Most helpful comment
I guess @Sairony is asking for all constants to be scoped under a particular namespace for their purpose. For example:
From that perspective, the user can enumerate the choices in a dropdown with
Object.keys(THREE.Wrapping)rather than having to maintain a matching list.All else being equal I agree the scoped constants might be nice, but this seems like a major a hassle to change now, so I'm not sure we can justify moving all the constants.