3 Minutes With Kent

I got a question (https://github.com/kentcdodds/ama/issues/247) on my AMA (http://kcd.im/ama) asking me about whether I prefer TypeScript (https://www.typescriptlang.org/) or Babel (http://babeljs.io/). I prefer Babel because it has better interop and a wider community. For more, listen to this 3 minute podcast :) See you all on twitter (https://twitter.com/kentcdodds)!

I've recently been working on prettier-eslint (https://github.com/kentcdodds/prettier-eslint) and an accomanying cli (https://github.com/kentcdodds/prettier-eslint-cli) and it's been a lot of fun. I really think that doing this kind of thing can really change the pace of your day-to-day and encourage you to do the same! See you all on twitter (https://twitter.com/kentcdodds)!

David asked me (https://github.com/kentcdodds/ama/issues/174) about my Deploy/Build process and it was easier to answer in audio form :) Links: What we can learn about testing from the wheel (https://github.com/kentcdodds/talks/tree/3bab77a70a42f15a6dc5519a8b964bb42efaab44#what-we-can-learn-about-testing-from-the-wheel) (my talk at Ignite Fluent 2016 (http://conferences.oreilly.com/fluent/javascript-html-us/public/schedule/detail/48271)) See you all on twitter (https://twitter.com/kentcdodds)!

My co-worker asked me about why the babel-plugin-lodash (https://github.com/lodash/babel-plugin-lodash) module is useful and I explain that and the lodash-webpack-plugin (https://www.npmjs.com/package/lodash-webpack-plugin) too :-)

I got a question (https://egghead.io/forums/lesson-discussion/topics/how-to-write-a-javascript-library-adding-es6-support#post-4659) about why we test our pre-transpiled code (or rather, instrument that code for coverage) rather than our post-transpiled code. So here's my answer. I reference babel-plugin-__coverage__ (https://www.npmjs.com/package/babel-plugin-__coverage__) (use this with karma) and nyc (https://www.npmjs.com/package/nyc) (use this with tests run in node, like with mocha (https://www.npmjs.com/package/mocha) or ava (https://www.npmjs.com/package/ava)). Good luck!

I had an enlightening experience today after hearing my 4 year old daughter Becca's response to watching some of the JavaScript Air (https://javascriptair.com) episode on webpack (https://jsair.io/webpack) today. Pam Selle (https://twitter.com/pamasaur) is a regular panelist.

I was asked (https://github.com/kentcdodds/ama/issues/137) on my AMA (https://github.com/kentcdodds/ama) about my opinoin on Test Driven Development (https://en.wikipedia.org/wiki/Test-driven_development) (or TDD).

Alex Booker (https://twitter.com/bookercodes) asks (https://github.com/kentcdodds/ama/issues/139): Hi, Kent I've seen you advocating Aphrodite on Twitter and noticed you're using it for the JavaScript Air site (https://github.com/javascriptair/site) Just wondering what drew you to Aphrodite over it's competitors (most notably Radium (https://github.com/FormidableLabs/radium)) I have a small amount of exposure to both and they seem to accomplish same thing but Radium is more mature Thanks P.S. I hope you're having a nice trip, mate

At first I was really bothered that AVA (http://npm.im/ava) didn't have support for nested tests, but now I consider nesting tests to be an anti-pattern. Here's an example of the kind of thing I mean (see this in a syntax-highlighted gist here (https://gist.github.com/kentcdodds/576c16d2069b3535aa4d7435082b186a)): Mocha with nesting (don't mind the actual tests, just imagine what this would be like with a larger test file): ```javascript import Customers from './Customers' import getMockCustomers from './Customers/mocks' describe('Customers', () => { let mockCustomers beforeEach(() => { Customers.setCustomers([]) // initialize to empty for most tests mockCustomers = getMockCustomers() // have mock customers available }) afterEach(() => { Customers.setCustomers([]) // clean up just in case }) describe('getCustomers', () => { beforeEach(() => { Customers.setCustomers(mockCustomers) }) it('should return the existing customers', () => { const customers = Customers.getCustom

Check out the Open Source Definition (https://opensource.org/osd). A license is required for your project to be considered Open Source. I recommend you choose a license (http://choosealicense.com/).

There are thousands of generators (https://www.npmjs.com/search?q=generator), boilerplates (https://www.npmjs.com/search?q=boilerplate), and starter kits (https://www.npmjs.com/search?q=starter+kit) available on npm right now. While these tools are super handy to get started, using them will bite you in the long run. I recommend that you make and use your own, and only use others as a reference.

I was just thinking about my AMA and decided that I'd talk about how I've found it to be valuable and encourage you to start your own! Here's mine: https://github.com/kentcdodds/ama Here's Sindre's: https://github.com/sindresorhus/ama

I was talking with my good friend Jamund Ferguson today and he mentioned that he just really likes the simplicity of using regular (non-preprocessed) CSS with BEM and here are some of the reasons I still prefer Aphrodite. I didn't mention in this that I also love that Aphrodite automatically vendor-prefixes everything for me as well. Hope this is helpful!

JavaScript Air (https://javascriptair.com) just passed 100,000 downloads on the audio podcast hosted by podbean.com (http://www.podbean.com/)

My friend Matt Winchester (https://twitter.com/mwinche) asked me (https://twitter.com/mwinche/status/718282311918362625) what I think of Aphrodite (https://github.com/Khan/aphrodite) compared to css-modules (https://github.com/css-modules/css-modules). Here's my answer. Here's an example of me migrating from CSS (processed with PostCSS (https://github.com/postcss/postcss)) to Aphrodite: https://github.com/javascriptair/site/commit/d8b8bf349f6c94a1d00539bb285240615baf5b7d (https://github.com/javascriptair/site/commit/d8b8bf349f6c94a1d00539bb285240615baf5b7d) Oh! And one other thing I didn't mention as a benefit of Aphrodite that can be a killer feature is because your CSS is colocated with the components that are using it, you can ship only the styles that are needed and used, rather than shipping ALL of your styles. A lot of problems go away when you have an explicit relationship between your styles and your components

Adam Morgan (https://twitter.com/atommorgan) asked me (https://twitter.com/atommorgan/status/718091846124056577) how I record audio and video for JavaScript Air (https://javascriptair.com). Here's my answer. Links: How to start a podcast like JavaScript Air (https://youtu.be/peIHG9gJb08?list=PLV5CVI1eNcJi8sor_aQ2AzOeQ3On3suOr) Mostly Node (http://mostlynode.com/) podcast Heil PR-40 (http://www.amazon.com/PR-40-Dynamic-Studio-Recording-Microphone/dp/B000SOYOTQ) microphone Heil HB-1 (http://www.amazon.com/Heil-Sound-HB-1-Steel-Microphone/dp/B004PJ414I) Microphone Boom Hangouts on air (https://support.google.com/plus/answer/2553119?hl=en) I hope this is helpful! Feel free to ask me more questions on my AMA (http://ama.kcd.im)

Just a quick explanation of how tools instrument your JavaScript code to record and report code coverage. Common tools: istanbul (http://npm.im/istanbul) nyc (http://npm.im/nyc) with ava (http://npm.im/ava) are great for coverage of node-running tests (use jsdom (http://npm.im/jsdom) to mock a DOM like I do (http://kcd.im/react-ava-repo)). babel-plugin-__coverage__ (http://npm.im/babel-plugin-__coverage__) karma-coverage (http://npm.im/karma-coverage) with karma (http://npm.im/karma) and the babel plugin are great for coverage of code when you want to run your tests in a browser isparta (http://npm.im/isparta) (no longer maintained, try the babel plugin) You may also be interested in this video (https://youtu.be/P-1ZZkpEmQA) + this repo (https://github.com/kentcdodds/random-user-coverage) where I go through setting up code coverage with ES6, Webpack, and Karma. Just replace where I use isparta with using babel-plugin-__coverage__ (like this (https://github.com/kentcdodds/es6-todomvc/blob/0c1b0afe31bad4713c51f

Just a quick pro-tip for those of you working from home. Keep the snacks outside of arms reach! And drink lots of water!

I've automated a ton of stuff for JavaScript Air (https://javascriptair.com). There's definitely still more to do, but I'm pretty happy with how much is automated. You can find most of the automation stuff in the npm scripts (https://github.com/javascriptair/site/blob/master/package.json#L7-L38) in the package.json (https://github.com/javascriptair/site/blob/master/package.json) in the repo (https://github.com/javascriptair/site). Many of these reference scripts found in the other directory (https://github.com/javascriptair/site/tree/master/other). Automation is great. In fact, this very episode used some of the automation found in this repo to make it mono and compress the audio. As I often say: Saving time is not the only reason to automate workflows (http://kcd.im/automation). See you on twitter (https://twitter.com/kentcdodds)!

For the last 24 hours I've been using Atom with vim mode and so far I'm liking it a lot. Here are the plugins I've installed so far: ava (https://atom.io/packages/ava) custom-invisibles (https://atom.io/packages/custom-invisibles) git-plus (https://atom.io/packages/git-plus) language-babel (https://atom.io/packages/language-babel) linter-eslint (https://atom.io/packages/linter-eslint) open-this (https://atom.io/packages/open-this) relative-numbers (https://atom.io/packages/relative-numbers) vim-mode (https://atom.io/packages/vim-mode) See you on twitter (https://twitter.com/kentcdodds)!