Handle external 'prop-types' correctly in prod build#488
Conversation
| root: 'ReactDOM' | ||
| }, | ||
| react: 'React', | ||
| 'react-dom': 'ReactDOM', |
There was a problem hiding this comment.
This can be simplified as it's target is window now
| filename: '[name].js', | ||
| library: dashLibraryName, | ||
| libraryTarget: 'umd' | ||
| libraryTarget: 'window' |
There was a problem hiding this comment.
Loaded unto window.dash_table in the browser
There was a problem hiding this comment.
Will changing how this is exposed have any side-effects for non-Dash users? Could you imagine anyone using RequireJS or anything else that expects a umd in their JavaScript project? I suppose, obviously, we wouldn't expect Node.js users (without a window global namespace) to be using this project. I'm also not sure if there's any webpack magic that makes this a non-issue.
There was a problem hiding this comment.
This should not have an impact.
| filename: '[name].js', | ||
| library: dashLibraryName, | ||
| libraryTarget: 'umd' | ||
| libraryTarget: 'window' |
There was a problem hiding this comment.
Will changing how this is exposed have any side-effects for non-Dash users? Could you imagine anyone using RequireJS or anything else that expects a umd in their JavaScript project? I suppose, obviously, we wouldn't expect Node.js users (without a window global namespace) to be using this project. I'm also not sure if there's any webpack magic that makes this a non-issue.
|
@wbrgss Yes. It will fix the missing prop types dep |
|
Adding a changelog entry and will merge afterwards. |
3 participants
This PR correctly externalizes
prop-typesfor usage as a library. It also exposes the library as a prop onwindowto be consistent with other Dash libraries.Would normally not update the build as part of a PR but this is included in another project through package.json and makes everything easier to handle on the other end.
"dash-table": "github:plotly/dash-table#prod-prop-types"