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

Tests: figure out why webpack resolver fails when webpack is present #1987

Open
ljharb opened this issue Feb 7, 2021 · 2 comments
Open

Tests: figure out why webpack resolver fails when webpack is present #1987

ljharb opened this issue Feb 7, 2021 · 2 comments

Comments

@ljharb
Copy link
Member

ljharb commented Feb 7, 2021

See d108b5d and #1986.

@rotu
Copy link

rotu commented May 23, 2024

I investigated one such failure:

The captures jam (array path) test currently fails if you have webpack installed. I believe it's because the appropriate field changed to resolve.mainFields: https://github.com/webpack/docs/wiki/configuration#resolvepackagemains

I'm not exactly sure:

  • what resolvers/webpack is supposed to do
  • why we have createWebpack1ResolveSync, createWebpack2ResolveSync but NOT, e.g. createWebpack5ResolveSync
  • why logic is based on the resolved version of enhanced-resolve and NOT that of webpack.

@ljharb
Copy link
Member Author

ljharb commented May 23, 2024

For bullet point 1, it's to allow this plugin to understand webpack specifier aliases, which which it can't.

For bullet point 2, it's either because resolution didn't meaningfully change, or, because nobody filed an issue about it. I suspect the former. If webpack 3, 4, or 5 have different resolution needs, then we should have those variations as well.

For bullet point 3, I'm also assuming that the issue wasn't webpack version as much as it was enhanced resolve version, but these changes predate me.

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

No branches or pull requests

2 participants