@aleccool21 The above regex only replaces imports of .less files. In your case it is a CSS. So just changes the less to css in the regex: .replace( /^(require|import).*\.css.*;$/gm , '' );

The syntax looks terrible and getting started is too difficult. I think it is really subjective. I see nothing off with the syntax, in fact I like it. Didn't experience any trouble getting started with it. If you use Webpack and css-loader, all you got to do is add a parameter modules to enable css-modules. I've seen far difficult setups with other front-end tools, this one is nowhere near those. CSS Modules really shine with a Webpack setup, and especially when your UI is modular. Why shouldn't one create sub CSS files using plain old methods and include them in modules? You don't get a local scoping for your CSS classes if you go this way. You would need to rely on (for instance) BEM naming to namespace your classnames. It is not automatic and you'd need to be very careful with the naming. On the other hand, the classnames CSS modules generates are automatic and guaranteed to be unique, even if classnames in your source files aren't.

The answer lies in your question itself :) Make sure your preprocessor is set up correctly and ensure your 'preprocessorIgnorePatterns' configuration is correct: http://facebook.github.io/jest/docs/api.html#preprocessorignorepatterns-array-string You need to add some code to ignore out the import of less files: // package.json "jest" : { "scriptPreprocessor" : "path/to/jest-preprocessor" , ... } // jest-preprocessor.js var babelJest = require ( "babel-jest" ); module .exports = { process: function ( src, filename ) { return babelJest.process(src, filename) .replace( /^(require|import).*\.less.*;$/gm , '' ); } }; Hope this helps.

If you mean testing of reducers then yes Tape could easily replace expect assertions. I am planning another writeup very soon for showing how to use Tape to test Redux reducers and action creators.

I think it is still a long way to go. Other browsers are not moving as fast as Chromium is.

It has to be Erlich Bachmann (T.J. Miller).

Nice writeup, though from what I see I would say @apply resembles more as SASS @include and placeholders than Mixins.

I think the best way to approach such a rewrite would be to migrate very gradually. Begin with your directives and convert them into React components. Then use ngReact to make them work first. This way you could backtrack easily if something is failing to work correctly in your app. I cannot recommend enough that you watch this amazing talk by Ryan Florence on how to approach a rewrite using React: https://www.youtube.com/watch?v=BF58ZJ1ZQxY After you convert all your directives to React this way, ideally your View layer should be now React. Next steps would be to rewrite the Angular Controllers, Models, Services etc. I recommend doing it with Redux for the controllers and plain JS modules for the services. Models would be just simple JS Objects. This would be also a great time you write some tests for the Reducers and Actions to ensure smooth migration. Never forget to migrate very gradually so that you're in control and isolating the cause for an issue is trivial.

Packages As far as Redux related packages go, so we haven't yet needed any packages besides the core redux and react-redux . Besides these, Reselect seems to be useful too from time to time. File Structure File structures are a really subjective. We use the following structure: src app common components ... account-settings actions __ tests__ action-1 .js action-2 .js ... index .js reducers __ tests__ reducer-1 .js reducer-2 .js ... index .js containers __ tests__ component-1 .js ... components __ tests__ pure-component-1 .js ... bundle .js profile actions reducers containers components bundle .js We divide stuff by modules, so the parts related to each module are near each other in a common parent folder. This saves us time from having to look far into other directories in search of components/actions/reducers/whatever related to the module we're working on. common hold common components, reducers or other piece of code that you could use across multiple modules. Each action/reducer/component/container has a __tests folder which holds tests for that particular concern. bundle.js contains the code for bundling up this particular module. It creates a store and uses Provider from the react-redux to render the app. Ajax Requests We simply use the request library. State management/flow We strictly follow the conventions and methods discusses by Dan Abramov in the official Redux tutorial . It has worked well for us so far.

Hey David, here's what my experience says: Always use branches: one branch for each task Group your branches as feature s, hotfix es etc: e.g. feature/twitter-login , hotfix/homepage-translation Commit early and often Use concise and clear commit messages Merge your main branch into your working regularly to get latest udpdates (applies when working in a team, helps avoiding huge merge conflicts) Learn how to rebase Never rebase collaborative branches, only a branch on which only you are working Learn enough git to be dangerous Follow a workflow consistently