Unexpected token import when running Non-Related React tests

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]

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?

[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.