Add babel/react/allowjs example

[trodrigues]

This is an example more tailored towards people who are using allowJs in mixed codebases where a migration to TypeScript is underway.

I also decided to keep testing and production setups outside of this as other examples cover that well and I often find it a bit confusing that some examples try to showcase so much stuff at once that if you're looking to solve a particular issue it can be hard to tell which specific settings are related to that issue.

[johnnyreilly]

Thanks - I'll try and take a look tomorrow. (Don't worry about the build failure - flaky test I believe)

[johnnyreilly]

This looks good. Couple of questions:

• what is babel transpiling to as a target?
• What version of ecmascript is it due to emit?

I have a feeling that you're really only using it for react transpilation rather than down-level stuff like emitting es5 code. That said, it would be good to be explicit about that in the readme if possible.

[trodrigues]

What babel transpiles to is usually defined by the preset, in this case https://github.com/babel/babel/tree/master/experimental/babel-preset-env

That means that what happens with this config is that typescript outputs ES2016 (our could be 2015, doesn't really matter) with the ES2015 module format. This is then consumed by babel and then passed down to webpack.

But you're right, babel isn't that much necessary here. I think when I initially came across this problem I needed Babel in this setup because I was still using webpack 1 at the time and webpack 1 didn't understand ES2015 modules yet. Now with webpack 2 Babel isn't really necessary to solve the initial problem I was trying to solve.

I also added an explanation of what that problem is to the readme file, but a more detailed explanation follows.

The reason as to why it is necessary to pass down modules as es2015 to webpack, is because there are some modules built with browserify (such as https://github.com/facebook/prop-types) which are exported in a way which typescript is able to consume but has some trouble exporting properly, while babel doesn't. The way this manifests itself is that when a user tries to access one of the properties exported by the prop-types package (such as PropTypes.string), it's not there, but it's instead in PropTypes.PropTypes.string.

I remember finding some issues in the typescript about this at the time I first came across this and how they decided not to fix this particular edge case, but I couldn't really find them again to link them here.

Anyway, given that this could possibly happen with other modules present on npm, the solution I figured out that works is the one described above: ensure that TypeScript isn't the one outputting modules down to what the browser will ultimately consume, but that webpack will take care of that instead.

[johnnyreilly]

Thanks!