Unexpected token import when running Non-Related React tests

[dschinkel]

Normally in any react project that is not a create-react-app app, you'd simply add the "ES2015" preset to get rid of this but for some reason, and knowing create-react-app is its own "animal" with how it works with babel under the hood because "everything is automated for you" which leaves me a black hole to deal with.

So that's why I'm posting this here. I have been able to run my react mocha tests just fine after adding the react-app preset in my package.json a long time ago. But I can't run my new develop mocha tests, for some reason I keep getting this error still:

above is an error during my travis build when it tries to run yarn run test.
This is output from Travis, not my local running of yarn run test.

My setup

I've got deployment code using ES6 imports in src/deploy/ and I have mocha unit tests exercising that code The deploy code is making various calls to aws S3 using their cli API to make calls. Travis looks at my travis.yml, and runs these scripts for this apps build process.

.babelrc - I added this because adding the react preset solved an error where jsx was not parsing in my react for some reason all of a sudden (I don't know why it decided to start to complain) and kept getting the error unexpected token on <MemoryRouter in app.spec.js in my test. Adding the react preset solved that
{
"presets": ["es2015", "react"],
"plugins": ["transform-object-rest-spread"]
}

Adding the "es2015" allowed me to rid the error Unexpected token import on my deployment tests when I run them locally...after adding the .babelrc to solve my other jsx parse error.

Adding the transform-object-rest-spread was necessary or else my deploy code wasn't able to use the rest-spread

So I can't fix this error above. If I take out .babelrc or take out "es2015" my tests no longer run locally. If I keep "es2015" + "react" presets, the tests run locally, but fail on travis, the error you see above in the screenshot.

I do not know why all of a sudden this test started to complain with the jsx parsing either:

I also recently upgraded to Node 8 and npm 5.0.3 to take advantage of some of the new utilities.

Any ideas?

[Timer]

Unfortunately, we're not able to provide support for using Mocha in conjunction with CRA.
I suggest you open an issue in a React community (e.g. reactiflux) or Stack Overflow, which is more suited for questions like these.

I would suggest you stop trying to fight against our configuration and utilize Jest, or switch to a different project.
This project has spent a lot of time honing our Jest configuration so it is painless to use, and we have not done the same for Mocha.
The use of Mocha is completely unsupported and reliant on you configuring it yourself.

With that said, I noticed a few things:

This looks like you're trying to use node to run a file which contains harmony modules syntax, which is expected to bomb. May I suggest you try using babel-node?

This is due to improper babel configuration (a missing plugin; see comments below).

---

I'm not sure why your tests are working locally but not in Travis; are you committing all of the files?
Is your .babelrc checked into source control?
Have you tried cloning a fresh version of your application and seeing if the error reproduces?

Also, you should be using babel-preset-react-app for maximum compatibility, not es2015, react, etc.

[dschinkel]

I think it's unfortunate that the team is so biased to only supporting Jest. A good tool should allow some flexibility especially on test frameworks. That's one of the reasons I don't suggest to clients to get locked into "complete solutions' for things.

As far as the screenshots above with the errors, those are from Travis trying to run my build. It was working just fine before with the same test script and this create-react-app, but all of a sudden had a fit. I wonder if it's due to upgrading to Node8 but I doubt it.

And I realize Facebook wants people using babel-preset-react-app. Which I am (I've set that in package.json and was hitting that prior to adding the .babelrc to try to troubleshoot weird issues). I had some issues with babel out of nowhere, that I couldn't resolve so tried any options I could to fix it due to the fact that it could possibly be due to create-react-app's babel config. I will say that using babel-preset-react-app completely locks you into this solution and into "black magic" because now you must use it if you decide to use create-react-app and totally reliant on Facebook. I don't recommend using this to anyone if it's just another canned product that's so proprietary you can'd do anything with it. Sure you can eject it which I see people doing, which makes me wonder why people don't just build from scratch in the first place. And it seems this is the case more often than not, that people need to do things in a real app that you can't do unless you "eject it".

Regardless thanks for taking a look at it
As far as a choice, my client wanted to use it, however I don't think they realize what a pain it is...as has many. You're on the verge of becoming another "canned solution" like meteor, microsoft's suite of tools, etc. you get the analogy here.

[dschinkel]

btw which harmony module syntax are you referring to?

You can start your app with babel-node app.js, but under the hood this still uses the babel/register hook

[Timer]

I think it's unfortunate that the team is so biased to only supporting Jest. A good tool should allow some flexibility especially on test frameworks.

It's not that we're bias towards Jest, but it is currently the best test runner for React projects.
You can view your case as anecdotal evidence; it's simply a pain to get Mocha working correctly.

The purpose of this project is to make opinionated choices and promote zero configuration.
Flexibility is not something we prescribe, and our users love this. Allowing flexibility would prevent us from rolling out updates or require too much churn.
Any users who require flexibility eject and are very happy with the honed configuration we provide for them.

It is not feasible for us to track multiple testing frameworks, such as Jest, Mocha, Ava, Karma, etc. There would be too many gaps and potential feature disparity between them.

That's one of the reasons I don't suggest to clients to get locked into "complete solutions' for things.

There's actually many benefits to a "complete solution".
Users receive free updates, a project which enables and promotes best practices, very useful development features and integrations to streamline development, and more.

As for being "locked into" create-react-app, this is completely false.
Create React App applications do not utilize any proprietary means of development style, and in most cases projects can be copy+pasted into other development frameworks with minimal (to zero) changes.
Additionally, you can eject at any time and gain complete control over everything.

As far as the screenshots above with the errors, those are from Travis trying to run my build. It was working just fine before with the same test script and this create-react-app, but all of a sudden had a fit. I wonder if it's due to upgrading to Node8 but I doubt it.

You should look back at what commit caused this to start happening, but I'm not sure how the breakage is related to us.
You can try to roll back your Node version, among other things. If you're using NPM 5, that might be the problem (improperly installing dependencies).

And I realize you want people using babel-preset-react-app. Which I am (I've set that in package.json and was hitting that prior to adding the .babelrc to try to troubleshoot weird issues). I had some issues with babel out of nowhere, that I couldn't resolve so tried any options I could to fix it due to the fact that it could possibly be due to create-react-app's babel config.

We don't "want people" using babel-preset-react-app; it's their choice to do so.
However, if you're doing something like you are, using babel-preset-react-app will give you maximum compatibility with the features CRA supports.

I will say that using babel-preset-react-app completely locks you into this solution and into "black magic" because now you must use it if you decide to use create-react-app and totally reliant on Facebook.

What "solution" are you referring to? I use babel-preset-react-app in many side projects (that don't use CRA / react-scripts) and it's very nice to have.
There's no "black magic", all of the source code is freely available here on github.

Sure you can eject it which I see people doing, which makes me wonder why people don't just build from scratch in the first place. And it seems this is the case more often than not, that people need to do things in a real app that you can't do unless you "eject it".

Many people eject because we provide excellent defaults & practices and can be used as a fantastic scaffolding solution.

Additionally, many people who eject do so wrongly. e.g. for Sass support.
You should never eject for Sass support. But tons of people do. Why? I don't know.

As far as a choice, my client wanted to use it, however I don't think they realize what a pain it is...as has many.

Then it sounds to me like you are disregarding your client's desire to use this tool. Using this tool includes using Jest.

Using Mocha is burdening them unnecessarily.
Did you explain to your client that using Mocha will prevent them from updating to newer versions of react-scripts without potential churn? You're nullifying many benefits of this tool.

You're on the verge of becoming another "canned solution" like meteor, microsoft's suite of tools, etc. you get the analogy here.

While I respect your opinion, I respectfully disagree. We have no proprietary requirements.

Like I said before, you're fighting against the tool instead of working with it. Why are you so opposed to trying Jest?

[Timer]

btw which harmony module syntax are you referring to?

http://2ality.com/2014/09/es6-modules-final.html

[dschinkel]

it's simply a pain to get Mocha working correctly

I can get it working in 1 minute tops..I'd love to know what is so "hard" about it..seriously.

[dschinkel]

It is not feasible for us to track multiple testing frameworks, such as Jest, Mocha, Ava, Karma, etc. There would be too many gaps and potential feature disparity between them.

I am not asking FB to support it. But obviously since everything is closed off, you can't do anything so naturally yea you can't plug anything into this like you could with any custom app.

[dschinkel]

Then it sounds to me like you are disregarding your client's desire to use this tool. Using this tools includes using Jest.

no my client doesn't care what I use to test with. I'm the one leading the project. I was just trying to accommodate the use of create-react-app but figured out that I should have never used it to begin with...now I know.

Using Mocha is burdening them unnecessarily.

sorry I'll call BS on that always. That's a reason FB uses to say "look Mocha is a pain" when it never was at all.

[Timer]

I can get it working in 1 minute tops..I'd love to know what is so "hard" about it..seriously.

This was simply an observation I've made based on this issue (broken testing) and #2167.

I am not asking FB to support it. But obviously since everything is closed off, you can't do anything so naturally yea you can't plug anything into this like you could with any custom app.

I'm not entirely sure how there's anything different with a CRA app versus your own application; both would require setup.

---

I'm going to close this issue because your original concern has been answered.
I'm sorry this tool doesn't work well for desires.
I wish it worked better for you, but I can't advise other than to stop fighting against it.

[dschinkel]

I won't get into why I'm opposed to Jest. And if I'm used to mocha or if someone's used to something else, at the least you should keep things open enough so that it allows it.

If you want to know what I have against FB and Jest you can read it here:

#2167 (comment)

https://www.codementor.io/daveschinkel13/running-mocha-enzyme-with-creat-react-app-84flnngkk

you're promoting excuses for developers not to write unit tests.

[dschinkel]

one final thing before I stop my rant

This was simply an observation I've made based on this issue (broken testing) and #2167.

right, usually it takes 1 minute but create-react-app closes off everyone. create-react-app is what caused me the pain with mocha, not setting up mocha as I normally do for any project which is dead easy. I get it like I said, but I don't think you should be closing things off to the point where you can't use a different test framework, that's ridiculous...luckily I came up with a work around

[Timer]

you're promoting excuses for developers not to write unit tests.

Where are you getting this information from?
What can you do with Mocha that you cannot do with Jest?

We actually recommend using enzyme for testing.
It's completely up to the developer to decide how they'd like to test their components.

We actually only have a small section about snapshot testing.
We explicitly say:

if the UI output changes, you get notified without manually writing any assertions on the component output

We do not claim that snapshot testing checks any sort of functionality.

---

I don't think you should be closing things off to the point where you can't use a different test framework, that's ridiculous...luckily I came up with a work around

Closing things off is that this tool does -- like I said before, if you don't agree with it, switch to a different tool (I know you said you cannot for this project).

[dschinkel]

We actually only have a small section about snapshot testing.
We explicitly say:

I'm talking about the Jest website, did you read the thread I had with #2167 (comment). It's a waste of time, we're not going to agree on it. Have a good one!

[dschinkel]

I still don't see what you're referring to I'm not using the harmony flag. And that link says nothing about babel-core vs. node-babel

This looks like you're trying to use node to run a file which contains harmony modules syntax, which is expected to bomb. May I suggest you try using babel-node?

What exactly are you referring to, what's wrong with babel-core/register? It's been working fine for me for 2 years.

that node command is something Travis does, not my code or my scripts. I don't run any of my scripts starting with node like that.