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

[hybridherbst]

Description

I'm somewhat confused why some import references are done this way:

• three.js/examples/jsm/loaders/MaterialXLoader.js

  Line 22 in ca7261b

  } from 'three/nodes';

This code seems to assume that something defines what three/nodes is.
In practice, that means that a importmap is required – and that it's hard to use this code at all when importmaps are not available (e.g. in most bundlers/frameworks).

In vite one needs to do something like this:

        resolve: {
            alias: {
                "three/nodes": "three/examples/jsm/nodes/Nodes.js",
            },
        },

and then in Next it's different, in bun it's different, ...

I know that previously great care was taken to use relative references throughout the codebase, e.g. here:

• three.js/examples/jsm/loaders/GLTFLoader.js

  Line 68 in ca7261b

  import { toTrianglesDrawMode } from '../utils/BufferGeometryUtils.js';

Is there a specific reason for when "indirect" references are used (not sure what the right name is) vs. when relative references are used? Are absolute references considered a bug / could I make PRs to fix them?

Version

r159

[Mugen87]

In practice, that means that a sourcemap is required

You mean import map, right?

[hybridherbst]

Yes, I mean importmaps :)

[marcofugaro]

In vite one needs to do something like this: ... and then in Next it's different, in bun it's different, ...

Wrong, we have the export namespace, so doing import { ... } from 'three/nodes' already works by default with modern tools.

Could you test it and report the actual issue?

[hybridherbst]

I would not have opened an issue if I had not tested this and came to the conclusion that this is the underlying issue.

I will double-check what's going on – simply removing the alias and letting vite do its thing results in three/nodes imports not being resolved at all in the particular project that I noticed the issue in, but works fine in empty new projects, so there may be additional (mis-) configuration going on.

I think the issue itself still stands – it's not clear which paths are when absolute and relative.

[donmccurdy]

Framing this the way around... is there a reason we need to use bare module names like three/nodes within our source files? It'd be nice for our imports to be consistent, most are relative, I'm not sure why three/nodes is the exception currently.

I agree that most modern tools support package.json#exports today, but not all, or not in all configurations. I've hit this occasionally and I usually work around it by just importing three/examples instead of three/addons, but the workaround is not so easy when our source files depend on the alias.

[marcofugaro]

simply removing the alias and letting vite do its thing results in three/nodes imports not being resolved at all in the particular project that I noticed the issue in

The problem is not related to this, it's something else in your setup.
Vite works fine with three/nodes: https://codesandbox.io/p/devbox/kr6x2c?file=%2Fmain.js%3A8%2C15

Framing this the way around... is there a reason we need to use bare module names like three/nodes within our source files? It'd be nice for our imports to be consistent, most are relative, I'm not sure why three/nodes is the exception currently.

Not really, I think it was done without much tought about it.
Any tool in particular that don't support package.json#exports?

[donmccurdy]

Parcel doesn't, for one. They've got support upcoming in v3 (not sure when that will be released), and some workarounds you can do in v2, but it's not out of the box last I checked.

Vite can handle exports sometimes, but still depends on your configuration. Add TypeScript to Vite and it will fail to handle exports as described here:

https://stackoverflow.com/questions/58990498/package-json-exports-field-not-working-with-typescript

That can be worked around (I have not tested this) by upgrading to TypeScript 4.7+ and setting your module resolution to "nodenext". But that's not a trivial workaround today, I'm not sure we want to require it from users without a clear reason.

[marcofugaro]

Parcel doesn't, for one. They've got support upcoming in v3 (not sure when that will be released), and some workarounds you can do in v2, but it's not out of the box last I checked.

Yikes, then yeah if there are some "modern" tool that still don't support it, it makes sense to use relative paths.

Vite can handle exports sometimes, but still depends on your configuration. Add TypeScript to Vite and it will fail to handle exports as described here:

Doesn't happen with the default typescript config, I believe it happens with a custom tsconfig.json, which is what might be happening in @hybridherbst's case.

[donmccurdy]

@marcofugaro interesting! Is that the default tsconfig from npm create vite@latest, or something else? I wasn't aware of "moduleResolution": "bundler".