Exclude core-js and babel-runtime from babel transformations

[glasserc]

Reasons for making this change

Discussion with @graingert suggests that issues #994, #991, and #1022 might be caused by a strange recursive webpack-babel-corejs configuration. Specifically, babel-runtime normally injects certain utility functions, or uses those of core-js, when it sees JS code that needs them. Our webpack configuration causes babel to be used on all our dependencies, including babel-runtime and core-js. Babel then injects the utility methods into the babel-runtime and core-js files that define the utility methods, leading to a circular dependency.

This fix excludes just babel-runtime and core-js from the dist Webpack configuration.

I'm not really sure how to test this without cutting a release. What I did to verify it at least a little bit:

• Remove --optimize-minimize from build:dist in package.json
• Run npm run dist
• Look through dist/react-jsonschema-form.js. defineProperty seems to be defined in 29, which requires 30, which requires 31, which requires 32, which requires 29
• Make changes to webpack.config.dist.js
• Rerun npm run dist
• Look through dist/react-jsonschema-form.js. 29 requires 30, which requires 31, which does not require anything.

There may be more clever ways to tell Webpack not to do anything silly, but we're running Webpack v1.13.3 (current is v4.20.2).

See also the discussion at the end of #982.

Checklist

• (n/a) I'm updating documentation
  • (n/a) I've checked the rendering of the Markdown text I've added
  • (n/a) If I'm adding a new section, I've updated the Table of Content
• (n/a) I'm adding or updating code
  • (n/a) I've added and/or updated tests
  • (n/a) I've updated docs if needed
  • (n/a) I've run npm run cs-format on my branch to conform my code to prettier coding style
• (n/a) I'm adding a new feature
  • (n/a) I've updated the playground with an example use of the feature

[graingert]

I think it might work without this

[graingert]

(eg delete line 38, you only need line 37)

[glasserc]

When I removed the babel-runtime element of the list, I got the same results as before (described in the PR notes as 29 including 30 including 31 including 32 including 29).

[graingert]

Oh ok, that's odd. LGTM otherwise

[graingert]

@glasserc it might be a good idea to release a .pre version to npm then test it out in a website via <script src="https://unpkg..."

[glasserc]

Good idea, thanks! I'll try that.

[glasserc]

I tried one of the tips-and-tricks ones (specifically, https://jsfiddle.net/hdp1kgn6/1/), and it failed before I published -pre.1 and it seems to work now. I'll cut a real release..

[graingert]

had a bit of a think about this - it might be better to use the regex form and exclude anywhere where '/node_module/core-js/' or '/node_modules/babel-runtime/' exists in the module path. That way it can cover nested deps with different babel-runtime or core-js versions

[glasserc]

Thanks for the suggestion. I opened #1040 as you can see to try to get webpack into modern shape. I'm not sure whether the changes are even still necessary -- looking at the output, it doesn't seem like anything is including itself any more, even without the change. Are you familiar with any change that would make webpack smarter in this regard? Think it's worth cutting another prerelease release without the exclude clause and see what happens?