Fix prop-types imports #26566
Fix prop-types imports #26566
Conversation
Details of bundle changes.Comparing: c8b7ad4...e491299 Details of page changes
|
|
Thanks for the work but at this point we're not merging any non-critical changes into |
|
Any rough ideas on when v5 may be released in that case? |
|
@eps1lon this very much is a critical change if it isn't working in the environment. More tools will move to static analysis of exports now that Node.js has standardized the approach, where prop-types very much fails that static analysis. Try for example: test.mjs Running This surely affects server-side usage in Node.js as well. |
|
@guybedford I'm not sure what you're referring to. We're not adding any features to v4. Supporting native ES modules is a feature. Our code didn't suddenly stop working as far as I can tell. If that is the case, please open an issue. Otherwise I'll ask you to stop pressuring library maintainers with this topic. It's not trivial for us to implement while also maintaining backwards compatibility. Right now we're getting pressure from every angle and I ask every one to be empathetic of each background. We do want to support ES modules. But ES modules aren't our only concern. We have ES modules vs CommonJS, IE 11 vs no IE 11, React 16 vs 17 (and upcoming concurrent React). Each of these combined with another create so many targets that we're no longer able to support every combination. And I'm going to be frank: This is not an issue of our making. From talks with other library maintainers ES modules is quite a large undertaking that the ES modules working group as failed to address. Now that everything has been finalized we're constantly getting pressured that this is "critical". If it would've been critical, then the collaboration should've been initiated months ago. Instead the working group did not find it relevant to reach out to library maintainers. And instead of offering help, we only get demands. I don't find that ok especially considering how other upstream "frameworks" engage with us. For example, |
|
Could you perhaps explain the resistance to this PR? If it fixes server
side Nodejs and is backwards compatible and is ready to go does that not
meet your maintenance criteria? I only used critical as mentioned here to
refer to not working on a target platform (server side Node.js). The PR
here implements this and is fully backwards compatible using a common
interop pattern. I can certainly empathize with the responsibilities of
open source, and the difficulty of the transition to ESM though.
…On Wed, Jun 2, 2021 at 12:50 Sebastian Silbermann ***@***.***> wrote:
@guybedford <https://github.com/guybedford> I'm not sure what you're
referring to. We're not adding any features to v4. Supporting native ES
modules is a feature. Our code didn't suddenly stop working as far as I can
tell.
If that is the case, please open an issue. Otherwise I'll ask you to stop
pressuring library maintainers with this topic. It's not trivial for us to
implement while also maintaining backwards compatibility. Right now we're
getting pressure from every angle and I ask every one to be empathetic of
each background.
We do want to support ES modules. But ES modules aren't our only concern.
We have ES modules vs CommonJS, IE 11 vs no IE 11, React 16 vs 17 (and
upcoming concurrent React). Each of these combined with another create so
many targets that we're no longer able to support every combination.
And I'm going to be frank: This is not an issue of our making. From talks
with other library maintainers ES modules is quite a large undertaking that
the ES modules working group as failed to address. Now that everything has
been finalized we're constantly getting pressured that this is "critical".
If it would've been critical, then the collaboration should've been
initiated months ago. Instead the working group did not find it relevant to
reach out to library maintainers. And instead of offering help, we only get
demands. I don't find that ok especially considering how other upstream
"frameworks" engage with us.
For example, import * as PropTypes from 'prop-types'; does not create any
type issues in TypeScript. It would've been more constructive to
communicate with TypeScript how they could catch these issue. But as far as
I can tell, nothing has been done. Maybe start with filing issues against
these upstream repositories instead of demanding "critical" changes from
downstream libraries.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26566 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAESFSQDHS3UGM2SMXVZ6RLTQ2DQPANCNFSM457D6LXQ>
.
|
We made the decision to not release features for v4 since we moved onto v5. Now maybe in your org it's viable to support multiple major release lines. It's not for us. |
|
In #26566 (comment), I think that the implicit implication was that if we could rebase on the import PropTypes from 'prop-types';not import * as PropTypes from 'prop-types';
@jollytoad We handle v5 as if it was the recommended version for production running application (minus the breaking change downside). We have even been encouraging developers to start from v5 since this year. |
A follow-up on mui#26566 (comment)
A follow-up on mui#26566 (comment)
Fix for #26564
I don't think this is a problem in
next, but we can't switch to that until it's released.