Evan Wallace

> And how will we be able to deal with sass/scss? If you are using another language that sits on top of CSS, you will likely always need to use...

But why are you doing this? Why not use the [standard `require` and/or `import` conditions](https://nodejs.org/api/packages.html#conditional-exports)?

What you are asking for will likely cause pain for users regarding `default` exports. If you import CommonJS into ESM then things mostly work as expected (both in esbuild and...

Ok. I will try to do the same thing for `conditions` that I do with `mainFields` then. Specifically: If you use `import` then esbuild will resolve twice, once with `module`...

I tried implementing this as described above. However, I'm having second thoughts about this. This could still introduce the dual-package hazard for package subpaths. The problem is that the decision...

I think the right way to do what the original post is asking for will be to use `--loader:.css=copy` once it's implemented: #2255. Doing what your plugin ended up doing...

> I don't know if you'd find that too specific to be in the core, but Yarn also makes a little change on the filesystem paths: if you have a...

Another idea: Once esbuild understands paths inside `.zip` files, you could potentially use the new-ish [`resolve` API](https://esbuild.github.io/plugins/#resolve) to reuse esbuild's internal logic for path remapping using `package.json` and other sources...

This is sort of blocked waiting on Yarn to expose the necessary data, which from what I understand is blocked on releasing another major version of Yarn. See https://github.com/yarnpkg/berry/issues/3591 specifically:...

Thanks for putting that together! Took a look. Some thoughts (keep in mind while reading that I don't use Yarn myself): * The specification doesn't mention `__virtual__`. Does that mean...