babel-plugin-transform-react-remove-prop-types alternatives and similar libraries
Based on the "App Size" category.
Alternatively, view babel-plugin-transform-react-remove-prop-types alternatives based on common mentions on social networks and blogs.
Do you think we are missing an alternative of babel-plugin-transform-react-remove-prop-types or a related project?
README
babel-plugin-transform-react-remove-prop-types
Remove unnecessary React propTypes from the production build.
Installation
npm install --save-dev babel-plugin-transform-react-remove-prop-types
The problem solved
Remove React propTypes
from the production build, as they are only used in development.
You can save bandwidth by removing them.
Example
In
const Baz = (props) => (
<div {...props} />
);
Baz.propTypes = {
className: PropTypes.string
};
Out
const Baz = (props) => (
<div {...props} />
);
With comment annotation
The majority of cases should be addressed by default by this plugin.
In some cases, for example when using HOCs (High Order Components), like react-redux's connect
, or component inheritance (although it's NOT recommended), a comment after the propTypes
definition may be used to force the removal:
Component.propTypes /* remove-proptypes */ = {}
Usage
Via .babelrc
(Recommended)
.babelrc
without options:
{
"env": {
"production": {
"plugins": ["transform-react-remove-prop-types"]
}
}
}
with options:
{
"env": {
"production": {
"plugins": [
["transform-react-remove-prop-types", {
"mode": "wrap",
"ignoreFilenames": ["node_modules"]
}]
]
}
}
}
Via CLI
babel --plugins transform-react-remove-prop-types script.js
Via Node API
without options:
require('babel-core').transform('code', {
plugins: [
'transform-react-remove-prop-types',
],
});
with options:
require('babel-core').transform('code', {
plugins: [
[
'transform-react-remove-prop-types',
{
mode: 'wrap',
ignoreFilenames: ['node_modules'],
},
],
],
});
Options
mode
remove
(default): thepropTypes
definitions are removed from the source code.wrap
: thepropTypes
definitions are wrapped with the following code:js Component.propTypes = process.env.NODE_ENV !== "production" ? { // ... } : {};
AccessingComponent.propTypes.className
won't throw. It's a tradeoff between the size of the output file and the likelihood libraries like react-native-hyperlink breaks.unsafe-wrap
: thepropTypes
definitions are wrapped with the following code:js if (process.env.NODE_ENV !== "production") { Component.propTypes = { // ... } }
AccessingComponent.propTypes.className
will throw.
The wrap modes are targeting React libraries like material-ui or react-native-web. They are not intended to be used by application authors.
removeImport
true
: the import statements are removed as well. This option only works ifmode
is set toremove
:js import PropTypes from 'prop-types'
false
(default): does not remove the import statements.
ignoreFilenames
This filter generates a regular expression. Any filenames containing one of the array's strings will be ignored. By default, we match everything.
Following the Is it safe? section, you might encounter a component
depending on the propTypes
at runtime to work.
For this reason, we provide an array options to filter out some files and folders.
For instance, you can ignore all the npm modules:
ignoreFilenames: ['node_modules'],
additionalLibraries
This option gives the possibility to remove other propTypes
in addition to the canonical prop-types
.
For instance, by default
import PropTypes from 'prop-types'
import ImmutablePropTypes from 'react-immutable-proptypes'
will result in the latter not to be removed, while with:
additionalLibraries: ['react-immutable-proptypes'],
both will be removed.
Regular expressions
If you are using Babel 7 or newer and your config is stored in babel.config.js
, you can also use a regular expression to describe modules, which should be removed.
This would be particularly useful when using custom prop types validators, implemented as part of your own source code. For example
import CustomPropTypes from '../../prop-types/my-own-validator'
import OtherCustomPropTypes from '../../prop-types/my-other-validator'
would be removed with the following setting
additionalLibraries: [/\/prop-types\/.*$/]
If you use an index file
import CustomPropTypes from '../../prop-types'
you could set it up as
additionalLibraries: [/\/prop-types$/]
classNameMatchers
Use this option to enable this plugin to run on components that extend a class different than React.Component
or React.PureComponent
.
Given this example:
class MyComponent extends BaseComponent {
...
}
You would use:
classNameMatchers: ["BaseComponent"]
createReactClassName
Use this option to set a custom name for the import of the create-react-class
package that is different than createReactClass
.
Given this example:
import createClass from 'create-react-class';
You would use:
createReactClassName: 'createClass'
Is it safe?
If you are using the propTypes
in a conventional way,
i.e by using them to perform type checking on the properties, that plugin should be safe to use.
However, some libraries are accessing the propTypes
on the component directly.
For instance react-native-vector-icons use them to split the properties between two components:
const touchableProps = pick(restProps, Object.keys(TouchableHighlight.propTypes));
:warning: The plugin is breaking that code if it ends up removing TouchableHighlight.propTypes
.
Make sure you are:
- Not using that pattern in your source code.
If you do, explicitly export the
propTypes
to work around that limitation. - Not parsing the
node_modules
. If you do, test that your code is still working before shipping into production.
eslint-plugin-react has a rule forbid-foreign-prop-types that can help you make this plugin safer to use.
License
MIT
*Note that all licence references and agreements mentioned in the babel-plugin-transform-react-remove-prop-types README section above
are relevant to that project's source code only.