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
Shouldn't loose-envify
be in devDependencies instead of dependencies?
#203
Comments
Anything that’s needed in production, even conceptually, is a runtime dep - so the fact that it’s included in a bundle doesn’t mean it shouldn’t be installed as a dep. |
Of course, but it's not the case for But I'm not sure of what you mean:
you mean "the fact that it's not included in a bundle doesn't...", right? Just to be sure I understood correctly. |
ahhh gotcha, i misunderstood. Yes, if loose-envify is part of the build process then it should definitely be a dev dep. |
@ljharb @autra the reason it was listed as a dependency rather than a dev dependency is because these lines tell the app level browserify to use loose-envify when processing the package (to remove the So prop-types@15.7.0 likely broke support for browserify. It would probably be better to do this in a major release, accompanied by the removal of the package.json lines that I linked. |
@billyjanitsch if that’s the case, we can revert it and put it back - can you help me by providing a quick test case to verify that it does indeed need to be a runtime dep? |
Sorry for that! I didn't intent to remove browserify support though, so maybe it's better to simply revert it? I see no other way if we want to keep this support. |
v15.7.2 is released; please file an issue if you see any problems! |
If I'm not mistaken, it's only used in the
umd
script in the package.json. If I understand correctly, this script builds a bundle for browsers, and will only be used in dev process.This would remove unused transitive dependencies when using a package that depends on prop-types.
The text was updated successfully, but these errors were encountered: