Babel-cli needed for running WebStorm's Test Runner

[dschinkel]

So I don't normally use create-react-app. I normally install babel-cli, babel-core, and whatever presets I need. I am using create-react-app this time and we have not ejected it.

So the docs here say babel doesn't need to be explicitly installed. Ok fine. But I see babel-cli isn't installed? I need it because I specify the node interpreter as node_modules/babel-cli/bin/babel-node in the WebStorm test runner but I don't see babel-cli installed at all via this boilerplate. I suppose I'll just have to install it manually then. Just wondering if that has any implications on the create-react-app scripts at all if I install babel-cli.

[gaearon]

I’m sorry—we don’t really have any specific WebStorm integrations, and I suggest you to raise an issue with WebStorm about this. cc @prigara

I don’t understand why babel-cli would be required. From #1871, my understanding is that this should be enough to set up the test runner in WebStorm: #1871 (comment).

[dschinkel]

There are a couple ways to tell Webstorm about babel:

Via mocha flag: --compilers js:babel-core/register

OR

Just tell it to use babel-node as the Node compiler which is under the babel-cli folder: babel-cli/babel-node. Since babel-cli is not installed by react-create-app, that won't work unless I manually install babel-cli.

With create-react-app, this which has worked fine in any normal project I've created (not with create-react-app) works fine: --compilers js:babel-core/register

But for some reason when I run this with create-react-app, I still get the ES6 import error:

SyntaxError: Unexpected token import
import React from 'react';

So webstorm is not able to resolve the ES6 preset for babel. I tried adding a .babelrc file with the preset es2015 and that usually works but because this is all configured and built into create-react-app, I don't want to manually be installing modules. So what module is automating this preset then? If I add es2015 the compiler complains that it's not installed so which is react-create-app using in node_modules for this then?

I don't have that problem otherwise when not using this boilerplate project.

[gaearon]

I believe I have already linked you to a comment showing a working configuration:

#1871 (comment)

I don't understand how this is related to Mocha because CRA uses Jest. Also, my impression is you don't need a Babel "compiler" when using CRA with WebStorm because CRA produces ES6 files itself.

I encourage you to search for "WebStorm" in issues. You will find instructions like this:

#519 (comment)

and this:

#519 (comment)

As you can see from them, you might be approaching the problem from the wrong end, as Babel needs to be disabled in WebStorm completely in a CRA-based project.

I hope this helps!

I am keeping the issue closed because this question has already been answered before. We’re using issues to track bug reports and feature requests. This is a support request about something that has been previously answered, so I’m not sure why it is valuable to keep it open.

Cheers!

[dschinkel]

I am not using Jest, I prefer mocha. Those links don't really answer my question because they're showing those trying to run Jest, not mocha with create-react-app. I don't think we're on the same page here, but thanks anyway.

[gaearon]

CRA already uses Jest out of the box. It might be possible to set it up to use Mocha instead, but you'd have to apply all the other (non-trivial) tweaks manually, so you might as well eject if you need to do it.

[dschinkel]

Well if they're non-trivial I haven't found them. :)

[gaearon]

I mean things like supporting the same extensions with sensible behavior including CSS. Not sure how you’d go about doing this in Mocha.

[dschinkel]

ok

[dschinkel]

I'm just going with installing the babel 2015 preset, adding a .babelrc and referencing babel-node. I don't really want eject nor does the team I'm working with. This will get me buy even though in the context of using create-react-app this is now considered a "hack" unfortunately.

[gaearon]

This won't fully work for you because the preset we use is not es2015. You can try using our preset (babel-preset-react-app) directly for a closer match.

[gaearon]

Is there some particular reason you are so opposed to trying Jest by the way?

[dschinkel]

There's no reason I should be forced to use Jest. Mocha is basically the same...Jest copied mocha, but I don't need all the stuff Jest claims to be helpful. I don't have time to switch to Jest, and I don't need snapshots either...I actually don't like snapshots for various reasons. I mock things custom, I don't need a mock framework. I keep things simple. Is that enough ? I like less magic. Want more? FB knows what they're doing with this, they're trying to pigeonhole and trap people into using Jest and I don't like that either. The very fact that I'm having trouble getting mocha to work with this is ridiculous. And I'm definitely not particularly happy with the FB team trying to push Jest Snapshots as replacement for unit tests. I can keep going on, if this entertains you.

[gaearon]

FB knows what they're doing with this, they're trying to pigeonhole and trap people into using Jest and I don't like that either

Wow.

I think Jest is more helpful for this particular project, and it took several months of concentrated effort from the Jest team to get it to the point where I chose to integrate it instead of Mocha. It’s cool if you don’t like it, but I would prefer if you avoided making assumptions about my motivations, as they are not only incorrect, but personally upsetting.

Choosing Jest here has less to do with it being an FB project (although being able to do a tighter integration nice), and much more to do with Jest having:

• a vastly superior interactive watcher with search
• a better diff view that is aware of React elements
• coverage, expectations, and mocking integrated (it’s cool that you don’t need them, but many do)
• snapshot testing (it’s cool that you don’t like it, but some people find it valuable)
• jsdom support out of the box

If you’ve been following Jest development, you might know that it was pretty bad compared to Mocha just a year ago. I wouldn’t have added it here if it stayed bad. You might also be interested in this discussion: #250 (comment).

I’m not here to change your mind, I was just curious if there was something specific about Jest you didn’t like that we could make better. If this is a matter of principle for you, I’m afraid I can’t help you.

The very fact that I'm having trouble getting mocha to work with this is ridiculous.

There’s nothing ridiculous about it. I made some choices in this project in good faith, picking the tools I find work well together. I understand there are people who prefer Browserify over Webpack, or Mocha over Jest, or Buble over Babel, but the whole point of this project is it is an opinionated config-free setup. So, naturally, you can’t expect the same hassle-free experience with arbitrary other tools that aren’t in it.

All I’m trying to say here is that your team specifically doesn’t want to eject, they probably value the benefits of the default setup (such as easy updates). On the contrary, you seem to enjoy configuring everything by hand and staying in control of that. Are your goals aligned with your team’s?

Bringing Mocha into the project, manually configuring it, and hooking it up with Babel etc is just negating these benefits (such as easy updates which are no longer easy). I totally understand you might not enjoy this particular setup, but in this case I encourage you either to discuss ejecting with your team, or perhaps fork react-scripts and replace Jest with Mocha in your fork. Then you can keep at least some of the benefits, as you still separate build setup from your app.

[dschinkel]

The team didn't pick this project for Jest. But obviously I will be stuck with having to use it. Yea it's opinionated that's for sure. They're cool with me using mocha but I found that this is a huge brick wall with this bootstrap

snapshot testing (it’s cool that you don’t like it, but some people find it valuable)

That's fine, but they shouldn't be marketed at a replacement for unit tests.

[dschinkel]

On the contrary, you seem to enjoy configuring everything by hand and staying in control of that

There are definitely things it's not going to include that I may need, this doesn't cover everything so yes, either eject or be constrained to what this requires. But, honestly all I wanted to do was a simple thing, plug mocha in. I get it, you're Jest fans. It's opinionated.

[dschinkel]

If you want to know where my main rant about Jest stems from for Snapshots it's here: https://facebook.github.io/jest/blog/2016/07/27/jest-14.html

One of the big open questions was how to write React tests efficiently. There are plenty of tools such as ReactTestUtils and enzyme. Both of these tools are great and are actively being used. However engineers frequently told us that they spend more time writing a test than the component itself. As a result many people stopped writing tests altogether which eventually led to instabilities. Engineers told us all they wanted was to make sure their components don't change unexpectedly.
Together with the React team we created a new test renderer for React and added snapshot testing to Jest.

And the main docs only show Snapshots as the way to test React Components, there are no examples of using Jest Unit tests + Enzyme as a key alternative (lets promote writing unit tests, and get developers to learn how to write better tests ay?). In fact if you even search for enzyme you barely find anything on it:

https://facebook.github.io/jest/docs/en/tutorial-react.html#content

Point being, snapshots is being painted as the "solution" for all React testing, and this to me is telling people hey you no longer need to write lower-level unit tests IMO. Consequently developers give up on unit tests and only write snapshots in a lot of cases I've seen.

people stopped writing tests altogether which eventually led to instabilities

I'm not you or FB but IMO, if this is the case and you're right, then we should be promoting good unit testing practices and mentoring people on how to write better tests, not promoting to just add magic. The Jest site could be promoting and adding videos on how to write unit tests, how to keep them decoupled so devs don't get "burnt" and don't "stop writing them", yada yada.

[dschinkel]

I'm not trying to insult you personally so don't take it as such. I just did not expect these problems today with trying to add a different test framework.

What I'm trying to do here is simply honor using create-react-app because that's what a team I'm working with prefers. But I'd like to use a different test framework without going full eject. Anyway thanks for your input. I had to be honest.

All I’m trying to say here is that your team specifically doesn’t want to eject, they probably value the benefits of the default setup (such as easy updates).

Yes you are correct.

I might be able to use this, but I don't like adding more "magic" on top of "magic". https://github.com/kitze/custom-react-scripts
https://medium.com/@kitze/configure-create-react-app-without-ejecting-d8450e96196a

The create-react-app app doesn't allow user configuration and modifications for few reasons:

Some of the babel presets and plugins that people might use are experimental. If they're used in a project and then they don't make it in the ES spec, they will break backwards compatibility.
It's hard to maintain code for all of these custom configurations that people want to use.
But people still want to use some of these features, and they're either ejecting their CRA app, or just don't use create-react-app because they're just missing X feature.

So instead of searching npm for a react-scripts fork with the X feature you need, this fork provides support for all of these extra features with simply adding a line in the .env config.

[dschinkel]

babel-preset-react-app worked so thanks for the input @gaearon on this.

I blog about the resolution here: https://www.codementor.io/daveschinkel13/running-mocha-enzyme-with-creat-react-app-84flnngkk

sorry I angered you, sometimes I'm kinda to the point and snapshots has been something that's been a thorn in my side me because I really think isn't something that should not directly or indirectly be promoted as a 100% replacement for writing isolated unit tests for React components...and IMO it's being presented that way all throughout the Jest site. This reminds me of things like MS Fakes, which I'm also not fond of. I think developers need to practice writing tests more instead of complaining that they got burnt. They're not writing tests right and we need to help them understand how to get better at doing so.

[gaearon]

Snapshots are not being promoted as a replacement anywhere. We use a combination of unit tests, snapshot tests, and integration tests at Facebook. If you saw some misleading articles about them I don‘t think it is very fair to blame the tool.

We use snapshot tests in places where we wouldn’t have tests otherwise. For example, for UI which is extremely volatile. A purist may say that everything should be covered by unit tests, but for some things it is just not practical. Snapshot tests work great for those cases where we would not have any coverage otherwise.

They are also extremely useful for command line tools (since their output is also very volatile). For example Jest and Prettier themselves use snapshot testing to avoid console output bugs and regressions, and it would have been extremely hard and time consuming to use unit tests for this.

To sum up, snapshots have their place, but they are not (and were never positioned as) a replacement for unit tests. They are complementary. They are also just one (and not very important for CRA) Jest feature, and we mostly chose Jest for other reasons (better test runner, test isolation, etc). I don’t think it is very wise to hold a grudge against a tool just because it has a feature you personally don’t hold valuable.

[dschinkel]

Cool. I don't have a grudge against the tool and I am saying there is a very important message your end users are not aware of, new to testing or inexperienced at writing tests. So what I have a grudge against is the fact that FB puts nowhere on the Jest site what you said above about the fact that you still should try to write isolated unit tests around React Components since Snapshots shouldn't be viewed as a replacement necessarily and that's stated nowhere in your docs. You stop short on that. And a lot of devs are not experienced at testing need to see that statement. All your examples show snapshots throughout the site in terms of testing React components.

I think that's a pretty important statement to have on the Jest site, but instead is I see statements that infer to a lot of devs new to testing (they don't know otherwise) that snapshots is a way to get rid of having lower-level unit tests. While you don't say exactly that, it's very inferred. The reason people fight lower-level unit tests are usually those who are new to testing or have gotten burnt by them not because lower-level are pointless (which they often conclude because they have not practiced it long enough to understand why..that unit tests aren't the culprit, it's lack of practice writing them).

Why not put this statement that they're not a replacement in that Jest 14 post and more importantly put that statement as the first line in your "Testing React Apps" section in Jest Docs. All I see when I click on "Testing React Apps" are mostly examples using snapshots! Why not add something like this:

"We at Facebook use a combination of Snapshots and Unit Tests to test react components. Snapshots are more integration tests. They are good for ...[insert what you said above, etc.] but they are not viewed as a replacement for lower-level isolated component tests here at Facebook".

People who are not experienced at writing tests need to understand that. There is a huge difference between integration and isolated unit tests...fundamental. Many just end up doing cargo cult and just "do what everyone else does" because they don't really try to understand more than snapshots....and "oh I hear from everyone else we can just use snapshots for everything". I'm not making that up, I see and hear that all the time from devs in Discord. A lot of people in Discord ask "should I use Snapshots or Unit tests to test my components". They're confused.

Anyway thanks for the input @gaearon

[gaearon]

So what I have a grudge against is the fact that FB puts nowhere on the Jest site what you said above about the fact that you still should try to write isolated unit tests around React Components since Snapshots shouldn't be viewed as a replacement necessarily and that's stated nowhere in your docs.

Raise an issue with Jest? I don’t think it’s out of malice or anything. If there are better ways to explain it in the docs, I’m sure the team would love to improve them! Or you could send a PR to the docs 😉

[dschinkel]

Sounds good I may contribute and send some PRs :).

[dschinkel]

For anyone NOT wanting to use Jest, here's the work-around https://www.codementor.io/daveschinkel13/running-mocha-enzyme-with-creat-react-app-84flnngkk