-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Automatically add module
condition to default ones
#2417
Comments
But why are you doing this? Why not use the standard |
We are generating People might also want to start using In general, we believe that One could say that in such a case we shouldn't be using |
What you are asking for will likely cause pain for users regarding Here's an example of a user struggling with this problem: #363. They had a package ( The specification for
Adding any |
I know about this danger... but I somewhat strongly believe that this should "just" be fixed on that package's side. Trying to use the so-called "auto" exports (instead of named) when transpiling down to CJS is just a big source of pain for users and it has been like that for uears. It's almost guaranteed to break one way or another and, like you mentioned, it already breaks in some bundlers (like webpack). For that reason I've abandoned this pattern years ago - it's not worth the . While there are different tradeoffs here to any potential solution and we could even attempt to disagree with the ones chosen by webpack... the status quo is that webpack is super popular and a package like this won't work with webpack. So while you have fixed~ this for esbuild users I think the problem is still in that package. I've also re-checked with Rollup to see how this is handled there and it seems that they introduce an interop runtime helper that allows for both to be used at runtime (
I agree with that to some extent - but as mentioned - I would consider this to be a problem at the library's side because its structure makes it incompatible with other very popular tools. At the end of the day, you will do whatever is good for your project in your eyes. I and respect that. I've just wanted to raise this as a potential problem because I've found out that esbuild is not adding this condition by default whereas other popular bundlers are. This makes my life even harder, as the matrix of potential configurations has increased because of that and figuring out how to satisfy different tools is/was already an almost impossible job. |
Ok. I will try to do the same thing for This way if your package is specified with This will only happen if you don't specify your own
I agree that the |
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 of "module or not" is made at each subpath. That's not a problem for "main fields" because they are only about the entry point, not about subpaths. So I think perhaps I should revert this for now. |
I was under the impression previously that Webpack used the |
I think this is a little bit complicated and that it still might cause ambiguities between consuming projects but I'm OK with this, better to have this than nothing from my PoV. What, IMHO, has to be preserved is the lack of dual package hazard as that's the whole reason to have the module condition in the first place.
"auto" exports were somewhat popular with
I guess that if you want to have this logic for using this condition conditionally, as described above, then the solution here would be to have this decision applied per package root?
From what I understand, @evanw is worried about |
@evanw thanks ❤️ |
As a package author, I'm trying to juggle a lot of requirements and keep it compatible with different tools. This is a mad man's world and, for now, we've decided to use
{ module: './esm-path.js', default: './cjs-path.js' }
in a set of our packages.However, this isn't ideal for esbuild users - our intention is for bundlers to pick up the
module
condition. This is how both webpack and Rollup work (without an explicit opt-in to this condition on the users' side). I think that Bun is also following the suit but I didn't recheck this right now so I might be mistaken. Is there a chance that esbuid could do the same?Somewhat related discussions:
#2173
#2163
#1956
I understand that you might want to follow the node's spec - but from my PoV that spec was designed mainly for node and it only defines how node should handle this field. It was deliberately designed in an extensible way though, giving other tools freedom to extend the semantics, adding new conditions etc. There was even an idea to create a centralized place where semantics for different new conditions could be defined as this is currently hidden in the implementations & docs of specific bundlers, even if the semantics are mostly shared between them (if only they use the same condition names, but tools try to do that and new conditions are not added on a whim).
Since esbuild is also a bundler I think it would make sense for it to behave in a similar way as other popular bundlers. Is there any particular thing that you are concerned about in relation to that condition?
The text was updated successfully, but these errors were encountered: