Help with resolving import maps issue with a locally linked fork of r137

Questions
1

So, I have a vite project where I use three. Unfortunately, I don’t use the official three.js npm package, but rather ought to use a fork which has some changes suited for my project’s needs.
This fork sits locally on my machine, and I use yarn link to link the fork to my project. Everything was fine up until r136 (well, my slightly modified version of r136), but when I updated my fork to r137 things broke down, and they’ve broken down because of the change regarding import maps introduced in r137.

I’ve added in my vite.config.js file the following:

import alias from '@rollup/plugin-alias';

...

plugins:[
      alias({
        entries: [
          {
            find: 'three',
            replacement: resolve(__dirname, 'node_modules/three/build/three.module.js'),
          },
        ],
      }),
    ]

This resolved all imports of the form import {Something} from "three" made in my project.

But imports of this from made in three’s example folder aren’t resolved. For example, the import from “three” in OutlinePass.js:

import {
	AdditiveBlending,
	Color,
	DoubleSide,
	LinearFilter,
	Matrix4,
	MeshDepthMaterial,
	NoBlending,
	RGBADepthPacking,
	RGBAFormat,
	ShaderMaterial,
	UniformsUtils,
	Vector2,
	Vector3,
	WebGLRenderTarget
} from 'three';
import { Pass, FullScreenQuad } from './Pass.js';
import { CopyShader } from '../shaders/CopyShader.js';

installing the official r137 from the npm registry doesn’t give me any problems.

I emphasize that none of the modifications made in my fork aren’t related to the build flow, or modules structure or anything like that.

I don’t know if it’s a general vite thing I’m missing, or something specific to the way the three package is included in the project via yarn link, and I realize it’s not exactly a three.js specific thing. Regardless I would apperciaite the help very much.

2

import maps have to do with user land, the published library is not involved in that. do you know what was changed between 136 and 137?

3

checking in unpkg both 136 and 137 pull from ‘three’ in examples/jsm, i think that shouldn’t be the issue. there was an older version where resolution was broken, it pulled from “…/…/…/build/trhree.module.js” or something like that, but it must’ve been earlier.

4

Just some shader code. Nothing relevant.

In r137 three introduced the need to use import maps to resolve the identifier “three”. So, I had to adapt my project (not the fork!) to that, so I’ve added the snippet above to my Vite configuration. As described in the OP, this seems to not be enough for the examples folder.

5

That’s exactly part of what was changed in r137 where they unified the imports to use the identifier “three”.

6

that isn’t something a library can do, it cannot require the need of using import maps. you are referring to the external html demos, but the library has little to do with that. import maps are not needed even in the latest three 152. it has to be something else.

7

136 UNPKG - three
137 UNPKG - three

both pull from “three” it seems. unless unpkg is mistaken.

but if that’s the issue and you really have strange relative urls, just alias “…/…/…whatever…three.module.js” to “three” in your rollup. that’s what we had to do before three finally fixed it. you don’t need import maps for that.

8

In here the import is by path.

In here the import is by the identifier.

9 
{
            find: '../../../build/three.module.js',
            replacement: resolve(__dirname, 'node_modules/three/build/three.module.js'),
},

or something like that. this was necessary before three fixed it by importing from “three”. i’m not familiar with rollup syntax, in webpack it had a different syntax but it also had to be done.

btw if it’s your fork anyway you might as well just search/replace these imports with “three” directly in the code, then you won’t have to mess with additional aliases. ../../../build/three.module.js was a bug or malfunction, it never had any sense.