Remove bsb dev setup suggestion

[justgage]

This setup causes problems in most projects because (at least in create-react-app based ones, probably many others):

• if you put __tests__ folder at the root (outside of src) it will not be picked up by Jest.
• if you put it in the src folder then bsb will try to double compile it and cause compiler errors.

Not doing this configuration is fine because the test files are never bundled with the other files, even though it's not in dev mode. It also follows Create React Apps best practices of putting test files next to the implementation ones.

[justgage]

I just changed the wording a little here. Mostly adding back-tics around things.

[coveralls]

Coverage remained the same at 97.978% when pulling cb824e6 on justgage:patch-1 into ad64578 on glennsl:master.

[glennsl]

This is an issue with create-react-app and probably several other over-complicated boilerplate generators making flawed assumptions. But then that's kind of their thing, and ought to be a reason to just not use it IMO.

if you put tests folder at the root (outside of src) it will not be picked up by Jest.

It should work fine if you run jest from the root of your project, which is where most people work from anyways.

if you put it in the src folder then bsb will try to double compile it and cause compiler errors.

I assume this is because you now have a source for both src and src/__tests__? Otherwise I don't see what would cause the problem, other than perhaps some magic from create-react-app. A workaround might be to have the first source point to a subdirectory like src/app.

Not doing this configuration is fine because the test files are never bundled with the other files, even though it's not in dev mode.

No, it's not. Dev-only sources and dependencies exist to isolate dev-time code and dependencies from production code and dependencies. This is especially important when developing a library to avoid consumers having to install unnecessary dev-time dependencies and compile code that might pollute the namespace and yield warnings or even errors that are completely unnecessary. But even when building an app you shouldn't have test modules polluting the production namespace, and the possibility of having production code accidentally depend on them.

It also follows Create React Apps best practices of putting test files next to the implementation ones.

One of the arguments don't apply to BuckleScript projects because there are no imports. The other is at best just preference, but is outright bad practice in BuckleScript for the reason explained above.

So the bottom line is: I'm not going to accept this as-is since it encourages bad practice. But if you can find a way to make it work with create-react-app and friends without significantly degrading the experience for everyone else, I'd be happy to. Otherwise this should be fixed at the source.

[justgage]

Yeah I was doing src/ and src/__tests__ initially.

Yeah I can see your viewpoint. I didn't think about the pure-reason library perspective. In this case it might cause problems. Webpack shakes out the tests from what I can see (probably because it does this with all __tests__ folders, at least with CRA's configuration).

I don't mind having test separated, however I feel that it's very foreign to JS developers, at least to my company.

I think I could settle for perhaps a warning for people trying to add bs-jest to an existing CRA project? I just found that I following the README.md verbatim has got me in trouble multiple times.

[glennsl]

Webpack shakes out the tests from what I can see (probably because it does this with all tests folders, at least with CRA's configuration).

Webpack starts from the entry point you give it and then recursively includes whatever is imported from there. So if you accidentally reference a test module (or more likely a module containing utilities for tests), that'll be included in the bundle too. It's not because tests are treated differently.

I don't mind having test separated, however I feel that it's very foreign to JS developers, at least to my company.

There's definitely an argument to be made for familiarity, but it's not exactly on the top of my list. Consider what bsb would have to do in order to enforce good separation. Instead of just having a special kind of container it would have to use a pattern that every source file is run through, with all the complexity and uncertainty that goes with configuring and testing that the pattern works as expected.

I think I could settle for perhaps a warning for people trying to add bs-jest to an existing CRA project? I just found that I following the README.md verbatim has got me in trouble multiple times.

Yeah, a footnote or something for CRA-users with actionable information would be great!

[justgage]

Closed in favor of my second try #50