Skip to content
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

Specify sourceType #6279

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

veltman
Copy link

@veltman veltman commented Jan 26, 2019

Resolves #6163, transpile a mixture of CJS scripts and ES modules in src/ by treating only files with import or export statements as an ES module.

Copy link
Contributor

@Timer Timer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we put this in the Babel plugin instead, please?

@Timer Timer added this to the 2.1.4 milestone Jan 26, 2019
@veltman
Copy link
Author

veltman commented Jan 26, 2019

Not sure whether there's a better place to nest this (e.g. options on a specific preset), so I put it in the main options for the preset. Feel free to move it if this isn't ideal!

@veltman
Copy link
Author

veltman commented Feb 5, 2019

Any thoughts on this @Timer?

@ianschmitz
Copy link
Contributor

I'm wondering if this could cause regressions based on what I read in their docs: https://babeljs.io/docs/en/options#sourcetype.

Specifically:

unambiguous can be quite useful in contexts where the type is unknown, but it can lead to false matches because it's perfectly valid to have a module file that does not use import/export statements.

@mifi
Copy link

mifi commented Mar 31, 2019

Anyone know why the travis build fails? I'm having the same problem. It's a very confusing bug because it doesn't say what's wrong with the code, it just says Attempted import error: ... is not exported from ...

In my case I had used array destructuring assignment like this:
const [x, y] = coords;
changing all instances of that into const x = coords[0]; const y = coords[1]; solved the problem, but it took me a few hours to figure out what was wrong with my code because it worked perfectly in Node.js

@veltman
Copy link
Author

veltman commented Apr 10, 2019

@Timer any thoughts on this? this still seems like a significant bug, I'm not sure if there's a better approach than forcing the sourceType though. Maybe there's some alternative Babel mechanism for defining the source type on a per file basis?

@danderson00
Copy link

Any progress on this? Happy to help out with some of the grunt work if it helps!

I recently upgraded react-scripts from 1.x to 3.0.1 and am now experiencing this when attempting to import a CommonJS module from an ES6 module. This worked fine before, and my understanding is that it should work? It's difficult for me to work around as I am sharing files between a react app and a nodejs app.

@yassine-be
Copy link

Is anyone on this ?
Same as @danderson00 we can't upgrade react-scripts from 1.x to 3.0.1 because of file sharing between a nodejs app and our react app.

@danderson00
Copy link

@yassine-be Though not ideal, you can work around this issue by replacing any object spread operators with Object.assign. There is a related issue - #7454.

@day-scene
Copy link

Is anyone on this ? I'd love to have this fixed.

@dmwyatt
Copy link

dmwyatt commented Feb 22, 2021

Yeah, this is still a problem. Any thoughts, @Timer?

@arcandio
Copy link

Just throwing my hat in on this one, hoping it's not too far out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Transpiling failure for module.exports syntax within src/