Please don't be too aggressive to using the new JS feature syntax in build files

[Molay]

Describe the bug

Please don't be too aggressive to using the new JS feature syntax in build files.

The syntax of ES2020 features has been used in the current code and these will cause problems in dependent projects.

Given that the Three.js project is extremely widely used in the community, I think we should be cautious about these new features and maintain backward compatibility.

It is too radical at the moment.

To Reproduce

Code

// File: three.js/build/three.module.js Line: 15293
this._setSize( texture.image.length === 0 ? 16 : texture.image[ 0 ].width ?? texture.image[ 0 ].image.width );
                                                                          ^------ ES2020 Nullish Coalescing

Live example

Expected behavior

We should avoid using new feature syntaxes prematurely in the build files, and provide good compatibility as much as possible.

Or put a backwards compatible version in the build folder at least.

Screenshots

Platform:

• Device: [Desktop, Mobile]
• OS: [Windows, MacOS, Linux, Android, iOS]
• Browser: [Chrome, Firefox, Safari, Edge]
• Three.js version: [dev, 0946935]

[Mugen87]

Given the support table of the nullish coalescing operator it seems appropriate to use it in the project.

https://caniuse.com/?search=nullish%20coalescing

[donmccurdy]

Related: #22618 (comment)

[Mugen87]

#22618 was solved by removing the problematic syntax from the code base.

However, I'm not feeling so well now with removing more modern syntax from the project without a clear policy 🤔 .

[Molay]

Just a proposal. This project should establish a specification.

For example, developers can use new feature syntax in source code, but also need to provide packaged library that is compatible with lower version of ECMAScript.

The essence of the current problem is that the project still uses the new feature syntax in the packaged library, which causes the dependent projects to crash with errors due to incompatible ECMAScript version when it is imported.

Development and release should be handled separately.

[donmccurdy]

Newer syntax is not just for developer convenience - it often runs faster than code transpiled to older JS versions. And in some cases (ES6 Classes) affects users' code in deeper ways.

I think my preference would be to pick a threshold that is modern but not bleeding edge (e.g. ES2018) and both write and release code within that threshold. For older browsers, I think it's a fair expectation that users must transpile the library to their specific target requirements.

[CodyJasonBennett]

Often, libraries will transpile their code when building with something like Babel to a version (often via browser targets) to ensure compliance, with further transpilation left to user-land. This is what R3F's babel config looks like, for example:

// https://github.com/pmndrs/react-three-fiber/blob/master/babel.config.js
module.exports = {
  plugins: [],
  presets: [
    [
      '@babel/preset-env',
      {
        include: [
          '@babel/plugin-proposal-optional-chaining',
          '@babel/plugin-proposal-nullish-coalescing-operator',
          '@babel/plugin-proposal-numeric-separator',
          '@babel/plugin-proposal-logical-assignment-operators',
        ],
        bugfixes: true,
        loose: true,
        modules: false,
        targets: '> 1%, not dead, not ie 11, not op_mini all',
      },
    ],
    // These are because R3F uses React & TS
    // '@babel/preset-react',
    // '@babel/preset-typescript',
  ],
}

This can get tricky for things like examples/jsm, which can't easily be generated. I've hinted at transpiling examples/addons in #23368 (comment), but tree-shaking examples seem to be a blocker for the time being (related: #23372, should probably centralize this issue to solicit contribution).

In any case, having the linter pick this up should keep syntax in check.

[mrdoob]

In any case, having the linter pick this up should keep syntax in check.

👍