adds jsnext:main field to package.json

[GGAlanSmithee]

Was surprised that the jsnext:main field was not added with #9310, so this PR adds it.

Adding this field will allow tools such as rollup (which is now used to bundle three.js itself) to perform tree-shaking optimization which might reduce bundle size considerably. See this.

@Rich-Harris I know you have been pushing for jsnext:main usage a lot, was there a specific reason why you left this out from your PR?

[GGAlanSmithee]

Also, another (arguably better) option would be too add another fille in the /build folder, which is bundled as a ES6 module and have jsnext:main point to that instead of src/Three.js. That way would be future compatible as the codebase gets ES6-ified

[Rich-Harris]

@Rich-Harris I know you have been pushing for jsnext:main usage a lot, was there a specific reason why you left this out from your PR?

I just felt it was a separate concern from the internal organisation of the codebase – agree that it'd be good to have a jsnext:main field now that it's possible.

Also, another (arguably better) option would be too add another fille in the /build folder, which is bundled as a ES6 module

That would be better – the issue with using src/Three.js is that it indirectly depends on the .glsl files in ShaderLib and ShaderChunk. That means anyone importing via jsnext:main would have to configure a transformer similar to the one in rollup.config.js, which is a confusing extra step (basically the same as libraries built with Webpack or Browserify expecting you to use the same setup as they do in order to use them – something I've railed against in the past).

In order to do that we'd need some additional build config (couldn't just use the targets option) because of the Three.Legacy.js and AudioContext stuff (which wouldn't work in the context of an ES output bundle – people would have to use getAudioContext instead). Using the --environment flag with a separate npm run build:es script would be the easiest way to do so without introducing an extra config file. I can hack on this when I'm back at work if you don't beat me to it :-)

[GGAlanSmithee]

@Rich-Harris thanks for your answer

it indirectly depends on the .glsl files in ShaderLib and ShaderChunk

Ah, did not think about that, agree that this should be handled by three.js

Your solution sounds reasonable, I played around with it for a while but I don't think I will have time to commit to make something proper.. This PR was a bit to naive I guess ;)

[mrdoob]

This PR was a bit to naive I guess ;)

Should it be closed then?

[GGAlanSmithee]

@mrdoob I left it open because I was considering revisiting it if I found time to, but let's close it and I can re-poen/create a new one in that case.

[Benjamin-Dobell]

In addition to the issues outlined regarding getting the rollup config right, there seems like there may be some more fundamental issues that need to be addressed.

In particular ObjectLoader and MaterialLoader have 11 occurrences of the following:

    new THREE[ data.type ]

This code assumes the THREE namespace has been defined, which won't be the case when working directly with three.js' modules.

This code probably doesn't get on too well with tree shaking either.

I noticed a similar, but different, issue was addressed in #9519

@Rich-Harris, any suggestions on how to make this work?

EDIT: In general there are 18 references to THREE within src/ that need to be snuffed out somehow.

[Benjamin-Dobell]

I guess the simplest (only?) solution is that any dynamically instantiable objects need to register themselves with a builder/mapping that knows how to look them up.

If we know that all files within certain directories contain a constructor matching their name and corresponding with the type string THREE.<filename without type>, then I guess a transformer could automatically generate the mapping.

@mrdoob How do you feel about replacing the dynamic class resolution within the THREE namespace with a string-to-constructor lookup?

[Rich-Harris]

@Benjamin-Dobell good catch! Looks like Loader.js, MaterialLoader.js and ObjectLoader.js are the only files affected.

A string-to-constructor/string-to-constant lookup would certainly be the most straightforward way to address this..

import { PlaneGeometry } from '../extras/geometries/PlaneGeometry.js';
import { PlaneBufferGeometry } from '../extras/geometries/PlaneBufferGeometry.js';
// ...

var geometryConstructors = {
  PlaneGeometry: PlaneGeometry,
  PlaneBufferGeometry: PlaneBufferGeometry,
  ...
}

/* later */

switch ( data.type ) {

  case 'PlaneGeometry':
  case 'PlaneBufferGeometry':

    geometry = new geometryConstructors[ data.type ](
      data.width,
      data.height,
      data.widthSegments,
      data.heightSegments
    );

    break;

This code probably doesn't get on too well with tree shaking either.

Unfortunately not, any app that imports e.g. ObjectLoader will also import all the different geometry constructors etc. Not sure that there's a good way around that.