We are in the process of moving entirely to ES modules, which is a large and long-running project already.
that sounds great! i think when it has progressed further packaging this up wouldn’t be much work
without packaging each example as an npm package.
i think this wouldn’t be necessary, just one package “three-examples” would be enough. it could have the bare esm modules and maybe a cjs folder where they are transpiled by rollup
Could you explain what you mean here? I’m aware that Node.js’s ES module support is messy, but it’s absolutely possible to get relative ES module imports working in Node.js.
SSR usually comes in ready-made solutions like Next or Gatsby. You don’t normally have to face node. A package that serves import statements is not expected in the npm eco system. Even if node gets esm, and it looks messy atm, jsm still breaks resolution.
Perhaps more importantly — what are we expecting SSR to do with THREE.WebGLRenderer?
SSR means the server sends a skeleton of the app, which renders quickly, and then gets hydrated on the client. THREE.Xyz has no use there, it just shouldn’t crash - but currently it does.
It isn’t related to SSR, though. Three/examples has a very unusual, and you could say broken, way of publishing its contents. It causes problems in lots of environments, SSR is one of them. This is also the reason why threejs/jsm is broken in Codesandbox or in any CJS env.