-
Notifications
You must be signed in to change notification settings - Fork 831
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
fix: allow prop-types to be removed in production #258
Conversation
fef2d8b
to
19f6876
Compare
On second thought, I would really like to solve this in such a way that we still retain the prop-types for developers. Otherwise there is little point in having them at all. |
Hm, I can't seem to get Also even if I could get it to work, potentially it would add its own issues since we'd have introduced
^ This seems like the most sensible and least invasive option. |
19f6876
to
290c284
Compare
OK, now this PR is just a refactoring to make prop-types removable, plus some instructions in the README for how to remove prop-types. Also I removed |
52efd51
to
be30bca
Compare
be30bca
to
f602208
Compare
This seems pretty uncontroversial to me now, so I'm going to self-approve and merge |
fixes #257
There were a few things required in order to actually remove
prop-types
from the build:shared-props.js
intoshared-props.js
andshared-default-props.js
, because one needs to be removed and the other one doesn't.additionalLibraries
option inbabel-plugin-transform-react-remove-prop-types
to catchshared-props.js
in addition toprop-types
removeImport: true
.I can confirm that this fixes the issue by running:
egrep -r '(prop-types|shared-props)' dist dist-es
And I observe that
prop-types
is only imported byshared-props.js
, andshared-props
is not referenced by any other module.Now, this PR raises the question of whether we actually want to unilaterally remove the
prop-types
from the npm package. If we do, then we lose the debugging benefits.However, I tried using the
"mode": "wrap"
option of the babel transform (to wrap everything in aprocess.env.NODE_ENV === "production"
check, and it ran into a runtime error for some reason.So perhaps a better solution is to build multiple versions:
Alternatively, we could make these code changes but not actually run the transform ourselves, but then provide instructions in the readme for configuring the transform. Then consumers of this library would be able to decide for themselves if they want to remove the
prop-types
.