Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No AMD shim when alias is referencing absolute path #616

Open
simonihmig opened this issue Mar 26, 2024 · 0 comments
Open

No AMD shim when alias is referencing absolute path #616

simonihmig opened this issue Mar 26, 2024 · 0 comments

Comments

@simonihmig
Copy link
Contributor

Related to #556, I have set up an alias to force using the ESM version of three.js, like:

alias: {
  three$: '/path/to/node_modules/three/build/three.module.js'
}

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant