You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This works fine when I have that config applied to a (test-)app, which is importing from three, and a v1(!) addon doing so as well.
However, when that addon was converted to v2, but nothing else changed, I get a runtime error in the test-app saying that the three module could not be found. And indeed - looking at chunk.app.js or require.entries - there is no AMD shim for three that the app's modules importing it would need.
It seems to me that shim only made it into the build via the v1 addon, and now that it is v2, that's not the case anymore. I still see the actual library code in a chunk though, which the v2 addon would be able to use, just no shim for the app!
I debugged this a bit where the alias is taken into account when resolving imports here, logging path, packageName and importedPath.
In the case of a v1 addon, the addon's import would show up as path='three' and packageName='three', so as if the alias is not taken into account!? 🤔 But without that early return (L319) it seems this would cause the AMD shim to be generated, and the bundled code is the ESM version of three.js nevertheless! For the import of the app, path would equal the alias (/path/to/node_modules/three/build/three.module.js) and with an absolute path instead of a package reference packageName would be undefined, thereby going into the early return block.
Now with the v2 addon, path would always be the alias, and packageName undefined, thereby always return type: 'local'. I assume that's where the change in output comes from!?
This comment made me want to try something out, so I hacked the code to return a type: 'package' object with the proper paths and stuff for three, and indeed that worked! The AMD shim was then present, and the app was working,
I am still not really able to connect the dots here though. @ef4 does that make any sense to you?
The text was updated successfully, but these errors were encountered:
Related to #556, I have set up an alias to force using the ESM version of three.js, like:
This works fine when I have that config applied to a (test-)app, which is importing from
three
, and a v1(!) addon doing so as well.However, when that addon was converted to v2, but nothing else changed, I get a runtime error in the test-app saying that the
three
module could not be found. And indeed - looking at chunk.app.js orrequire.entries
- there is no AMD shim forthree
that the app's modules importing it would need.It seems to me that shim only made it into the build via the v1 addon, and now that it is v2, that's not the case anymore. I still see the actual library code in a chunk though, which the v2 addon would be able to use, just no shim for the app!
I debugged this a bit where the alias is taken into account when resolving imports here, logging
path
,packageName
andimportedPath
.In the case of a v1 addon, the addon's import would show up as path='three' and packageName='three', so as if the alias is not taken into account!? 🤔 But without that early return (L319) it seems this would cause the AMD shim to be generated, and the bundled code is the ESM version of three.js nevertheless! For the import of the app,
path
would equal the alias (/path/to/node_modules/three/build/three.module.js
) and with an absolute path instead of a package referencepackageName
would be undefined, thereby going into the early return block.Now with the v2 addon,
path
would always be the alias, andpackageName
undefined, thereby always returntype: 'local'
. I assume that's where the change in output comes from!?This comment made me want to try something out, so I hacked the code to return a
type: 'package'
object with the proper paths and stuff forthree
, and indeed that worked! The AMD shim was then present, and the app was working,I am still not really able to connect the dots here though. @ef4 does that make any sense to you?
The text was updated successfully, but these errors were encountered: