Jerome Covington

Allowing developers to handle their own polyfills is desirable in general and more forward-thinking, provided the specific polyfills that meet BB's requirements are clearly documented as such.

+1 @Cleod9 re: error handling. Inadvertently handling errors with a `.catch()` without re-throwing up the Promise chain can be a huge source of debugging confusion.

In addition to the above, the docs should be revisited wrt `ts-migrate-full`, as that package does not seem to exist. ```shell $ npx ts-migrate-full . npm ERR! code E404 npm...

No I have left the Podfile untouched. For this project I am using the Expo build process and do not want to create any diffs to the default native code.

@Poky85 I'm seeing this issue in my own codebase as well, and want to verify what is causing the behavior, so that I can demonstrate that @alexindigo's [solution](https://www.npmjs.com/package/webpack-chunk-hash) solves this...

I am also using the `CommonsChunkPlugin`, so any shared `import`-ed modules end up getting bundled as `require` statements in the `common` bundle. And any resulting additional `require` statements in `common`...

Great, thanks @alexindigo I have been able to reproduce the behavior and will now be on track to verify the solution you published on npm.

Yep, @alexindigo seems to be working out well. Thanks for taking the time to publish on npm and answer my questions!

Hm. I seem to be running into this issue again, using `webpack-chunk-hash` where it seems that the chunkhash digest is being produced prior to the module id insertion. In this...

Ah, I see you added ids back into the hashing mechanism. I will take the update to your plugin and let you know how it goes, @alexindigo.