fix unnecessary filtering of absolute aliases

[jonrimmer]

Changes

As per discussion #2413, stop esinstall from ignoring aliases just because they are absolute.

Filtering out absolute aliases breaks one of the main use-cases for aliases—replacing a dependency imported by 3rd-party code with a shim, a polyfill or other locally supplied alternative. The discussion gives the concrete example of Chart.js importing Moment.js, but undoubtedly there are more.

Testing

Ran yarn test and ran the modified Snowpack against my project to confirm the change fixed the issue.

Docs

No, because this was never documented behaviour.

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/pikapkg/snowpack/7paxj3574
✅ Preview: https://snowpack-git-fork-jonrimmer-fix-alias-filtering.pikapkg.vercel.app

[FredKSchott]

I actually had the same thought when I was just in that code the other day.

The only thing to look out for is that this opens the door for a new bug in Snowpack: If I wanted to create an alias in my own application (ex: $components/* to ./src/components) then that alias now applies within all dependencies as well. Worse, because of the fact that we're pre-bundling deps, that source code would now get bundled in with the package.

Maybe that's pretty rare, if your alias is also a package name then you're probably already going to run into trouble.

But I wonder if there's a better solution than alias for this problem.

[jonrimmer]

@FredKSchott Good point. Taking another look at the sources here, I notice that esinstall has a config field called importMap that seems like it might work to re-map package imports everywhere. Could it be as simple as exposing this config on the Snowpack resolve config object alongside alias?

[FredKSchott]

#2707 now brings package handling and build handling together, so this behavior now makes more sense. I think this is okay to merge and release as a part of that PR & a larger v3.1.0 release.

Thanks again for the help!