JS Development Environment

• VS Code Terminal
• Node Security Platform
  • Install: npm install -g nsp
  • Run security check: nsp check
• Development Webserver
  • Browsersync*
  • Express
• Sharing work-in-progress
  • localtunnel*
    • Default run: lt --port 3000
    • Custom url: lt --port 3000 --subdomain gregg
  • ngrok - secure
  • now
  • Surge - static html files
• Automation
  • Grunt
  • Gulp
  • npm scripts
    • npm start
    • npm run share
• Transpiler
  • Babel*
  • Typescript
  • Elm
• Bundlers (5 Module formats)
  • IIFE
  • Asynchronous Module Definition (AMD)
  • CommonJS (CJS)*
  • Universal Module Definition (UMD)
  • ES6 Modules*
    • Standardized
    • Statically analyzable
      • improved autocomplete
      • intelligent refactoring
      • fails fast
      • tree shaking: dead-code elimination
    • Easy to read
      • named imports
      • default exports
• Bundlers
  • Browserify: simple
  • Webpack: comprehensive (CSS, images, fonts, html)*
  • Rollup: tree-shaking performance
  • JSPM: runtime loader
• SourceMaps
  • Debug transpiled and bundled code
  • Map code back to original source
  • Downloaded if you open dev tools
• Linter
  • JSLint (Crockford)
  • JSHint
  • ESLint (current standard)*
• Testing and Continuous Integration
  • Testing Framework
    • Mocha* (popular, configurable)
    • Jasmine (popular)
    • Tape
    • QUnit
    • AVA
    • Jest
  • Assertion Libraries
    • Chai*
    • Should.js
    • expect
  • Helper Libraries
    • JSDOM* (simulate DOM in memory)
    • Cheerio (jQuery for server)
  • Where to Run Tests
    • Browser
      • Karma, Testem
    • Headless Browser
      • PhantomJS
    • In-memory DOM
      • JSDOM*
  • Where Do Test Files Belong?
    • Centralize
      • Less "noise" in src folder
      • Deployment confusion
      • Inertia
    • Alongside*
      • Easy imports
      • Clear visibility
      • Convenient to open
      • No recreating folder structure
      • Easy to move files
  • When Should Tests Run?
    • Unit Tests should run when you hit save
• Continuous Integration
  • What does CI do?
    • Run automated build
    • Run your tests
    • Check code coverage
    • Automate deployment
  • CI Servers
    • Travis* (linux)
    • Appveyor* (Windows)
    • Jenkins
    • CircleCI
    • Semaphore
    • SnapCI
• HTTP Calls
  • HTTP Call Approaches
    • Node
      • http
      • request*
    • Browser
      • XMLHttpRequest
      • jQuery
      • Fetch*
    • Node & Browser
      • isomorphic-fetch
      • xhr
      • SuperAgent
      • Axios
  • Why Centralize API Calls?
    • Configure all calls
    • Handle preloader logic
    • Handle errors
    • Single seam for mocking -Why Mock HTTP?
    • Unit Testing
    • Instant response
    • Keep working when services are down
    • Rapid prototyping
    • Avoid inter-team bottlenecks
    • Work offline
  • How to Mock HTTP
    • Nock
    • Static JSON
    • Create dev webserver (api-mock, JSON server, JSON Schema faker, BrowserSync, Express)
  • Our Plan for Mocking HTTP
    • Declare our scheme
      • JSON schema faker
    • Generate Random Data
      • faker.js
      • chance.js
      • randexp.js
    • Serve Data via API
      • JSON Server
        • npm run start-mockapi
        • http://localhost:8080/users
• Production Build
  • Minification
  • Sourcemaps - code debugging
  • Dynamic HTML
  • Cache busting
    • Hash bundle filename
    • Generate HTML dynamically
  • Bundle splitting
    • Bundle splitting: http://screencast.com/t/UhqgXJwwaiq
    • CSS bundle with hash: http://screencast.com/t/jseE4draJ8
  • Error logging
    • TrackJS*
    • Sentry
    • New Relic
    • Raygun