Transpiling failure for module.exports syntax within src/

Created by: veltman

I don't think this is necessarily a bug, and may be related to the 2.0+ changes to transpilation, but...

Steps to reproduce (I was using Node 10.13.0, if that matters):

Create a new create-react-app project with react-scripts@2.1.2.
Create two files: src/es6.js and src/cjs.js.

// es6.js
export default ({ foo, ...rest }) => true;

// cjs.js
module.exports = ({ foo, ...rest }) => true;

Run yarn start.
Import both of them into App.js, one at a time:

import es6 from "./es6.js";
// or
import cjs from "./cjs.js";

The use of the Object rest/spread syntax is allowed in the ES6 module syntax but not in the CommonJS module.exports version.

In the latter case, you get one of two errors, depending on whether it's the first attempt to build or a subsequent attempt:

Attempted import error: './cjs.js' does not contain a default export (imported as 'cjs').

or

TypeError: Cannot assign to read only property 'exports' of object '#<Object>'

If you don't use the rest/spread syntax, and just use plain destructuring (e.g. ({ foo, bar }) => true), both files work.

It seems like this has something to do with the dynamic module.exports triggering a different transpilation, but I'm not sure exactly what's happening. It clearly does get transpiled - if you inspect the built output, it's been rendered ES5-compatible. But the rejection of the rest/spread indicates that the CJS file is getting transpiled... less?

Is this the intended behavior? Should CJS modules in src/ have a different set of language features allowed than ES6 modules? If so, is there a point in the config where this behavior can be changed? Am I missing something obvious?