Three.js source does not work as ES6 module

[arodic]

Description of the problem

Three.js source cannot be imported as ES6 module. Developers should be able to use Three.js in pure ES6 module form.

For example, the following should work:

<script type="module">
import * as THREE from "./src/Three.js";
</script>

Instead, we get errors like this one:

Failed to load module script: The server responded with a non-JavaScript MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec.

This happens because glsl shader chunks are not real modules and need to be processed during build step by rollup glsl plugin.

Fixing this would improve development experience and make it possible to use threejs without build step or even without any npm dependencies at all.

Motivation

ES6 modules are a great improvement to JavaScript. Together with HTTP/2 network protocol which eliminates multiple HTTP request overhead they enable seamless development experience without continuous build process. Building, bundling and minification should most definitely still be part of the deployment strategy, but for development process, it is not necessary. Here is an interesting article about ES6 modules by contentful.

This issue is about enabling threejs to work without any build process and without npm install during development.

Suggested solutions

1. Rollup ShadersChunkSrc.js into ShaderChunk.js separately before building the library. This solution was attempted in PR ShaderChunk to ES6 Module #14447 but it did not reach consensus. Main issue was that this approach results with a partial "build" inside src/ directory.

2. Convert each individual glsl shader chunk into ES6 module (automatically). This approach would suffer from the same issue as no.1 but some prefer it better.

3. Rewrite and maintain shader chunks as ES6 modules using template literals. For example:

var encodings_fragment = glsl`
 gl_FragColor = linearToOutputTexel( gl_FragColor );
`;
export {encodings_fragment};

4. Another solution suggested by @looeee: do nothing (or write better documentation): it will not be possible to import the three.js src directly in the browser, and people bundling the source themselves have to add plugins such as glslify to their build step (as they currently do)

Three.js version

• [x ] Dev

Browser

• All of them

OS

• All of them

[arodic]

1. Rollup ShadersChunks.js into ShaderChunksBuild.js separately before building the library.

I already tested this approach and it works.

2. Convert each individual glsl shader chunk into ES6 module (automatically).

This should work but having shader chunks in both glsl and js form might confuse some developers.

3. Rewrite and maintain shader chunks as ES6 modules using template literals.

Problem with this one is that glsl template literals don't have syntax highlighting by default so developers would need plugins for their code editors.

[mrdoob]

3. Rewrite and maintain shader chunks as ES6 modules using template literals.

Problem with this one is that glsl template literals don't have syntax highlighting by default so developers would need plugins for their code editors.

Also, the glsl rollup plugin does some minor string clean up (removes comments).

[arodic]

Also, the glsl rollup plugin does some minor string clean up (removes comments).

@mrdoob yeah I'm not sure why it didn't remove comments in my PR but it appears there were other issues. It appeared that most people don't like partial builds in src/ directory. That leaves solution 3. and 4. only candidates for now.

Also, keep in mind that template literals can in fact strip out comments (they are actually functions). Moreover, comment stripping can still be done during build process.

[looeee]

Another solution suggested by @looeee: do nothing (or write better documentation): it will not be possible to import the three.js src directly in the browser, and people bundling the source themselves have to add plugins such as glslify to their build step (as they currently do)

To be clear, this was not so much a suggestion as an explanation of the current situation. I don't currently have a strong opinion as to what the best approach is here.

[arodic]

I just pushed solution no.3 (template literals) to shaderchunk-template branch to illustrate what I meant. I don't expect this solution to be accepted.

This works as ES6 modules and does not require build step whatsoever but has several issues:

1. No syntax highlighting by default.
2. Not supported by IE.
3. Still requires rollup plugin to remove comments.
4. Deviates from glslify format.

[Itee]

@arodic Did you take look at three-full ? All shaders are put in the same folder and are es6 modules. In that way you should be able to import them in the way you want. Waiting that #9562 be close.

[dmnsgn]

@arodic @mrdoob Just created a straightforward PR that could help with syntax highlighting of glsl templates literals: #15473 (more infos in PR)

 // Advantage here is that there would be no need for a glsl tag function, just a comment
+ var encodings_fragment = glsl`
- var encodings_fragment = /* glsl */`
  gl_FragColor = linearToOutputTexel( gl_FragColor );
 `;
export {encodings_fragment};