Nodes: use relative references inside examples/jsm

[hybridherbst]

Fixes (at least partically)

• three/nodes requires package.json#exports or import maps, consider relative imports #27354

Description

These are the only places where importmaps are currently required when accessing code from examples/jsm.
All other places that import from three/nodes are either inside example HTML files (that have importmaps) or inside the playground folder.

CC @sunag; is there a specific reason for why three/nodes is used? I understand that the location of this code may change again but I think then the paths should be adjusted instead of in the meantime requiring users to go through hoops with various bundlers to get these references to work.

[marcofugaro]

I understand that the location of this code may change again but I think then the paths should be adjusted instead of in the meantime requiring users to go through hoops with various bundlers to get these references to work.

Could you share a test of this import being an issue?

is there a specific reason for why three/nodes is used?

We recommend the users to import from three/nodes rather than using the three/examples/jsm/nodes/Nodes.js path, both in the web environment (with import maps) and node environment (works by default). So having this import in the source code doesn't currently pose a problem.

[hybridherbst]

I commented on the referenced issue. Once that is resolved happy to close this PR if really wanted.

[sunag]

I think this PR follow part of work: #25904

[LeviPesin]

Can we please reconsider this?

Using relative paths feels really like a hack -- first, three/nodes is much more readable than a relative path, second, importing from a relative path may lead a user to an idea of importing a node directly from its file, which is NOT supported and may lead to breaking everything (only importing the main Nodes.js file is supported).
Third, hardcording paths significantly complicates just copying out a directory or two (core, nodes, renderers) from the repo and then easily allowing them to resolve each other using import maps -- I understand this might not be such an issue nowadays because of less usage of such a workflow, but still... Why hardcode paths when you may just not hardcode them?

@mrdoob @Mugen87 @sunag @hybridherbst @marcofugaro

[hybridherbst]

@LeviPesin see #27354 for a lot of discussion on the "why" and the current status of bundlers respecting or ignoring the virtual paths defined in package.json.

I think calling relative paths "hardcoded" and virtual paths, that may or may not be resolved correctly depending on the environment, "not hardcoded" is a misnomer...

For all of our projects we're using explicit import paths for that very reason, the virtual paths three/addons and three/nodes are not usable in too many circumstances. I still think keeping three.js clean of virtualized paths is the better approach.

[LeviPesin]

I think calling relative paths "hardcoded" and virtual paths, that may or may not be resolved correctly depending on the environment, "not hardcoded" is a misnomer...

I understand that some (quite old already) browsers don't support import maps -- that what is the polyfill for them for. But if bundlers have issues with supporting them -- I would consider this more of a bundlers problem rather than a problem of using virtual paths...

[hybridherbst]

I would consider this more of a bundlers problem

I agree but it doesn't change that three.js is not usable in these cases. It's not the "dead 0.2%" of cases unfortunately, there's quite some popular combinations that currently don't support these virtual paths (e.g. vite + svelte/sveltekit). Where I can I already open issues with these bundlers.