Next post: How to transfer files from a Windows 98 VM

Typescript 2020 template

How I start a typescript webapp in 2020

If I’m starting a vanilla javascript app, rather than react, here’s a good starting point, with a lot of convenient features & my own helper scripts.

A link to the code is on my github:

How to use it:

  • Run npm run start to build for development
  • Run npm run build to build for production

What’s inside:

  • My helper scripts
    • add-assert-markers, which adds a unique string to every assert in your code
    • prettier-except-long-imports, which runs prettier but excludes import statements at the top of your code
    • typescript-super-auto-import, which automatically discovers typescript dependencies within your project and adds import statements. It can optionally also enforce the layering order of your modules.
  • release builds are bundled to a single file
    • better because there are fewer network requests, unless there’s SPDY
    • better because some browsers like old mobile android don’t yet support es6 modules
  • release builds are minifed
    • doesn’t save download time because of gzip transfer
    • but better to make reverse engineering of commercial projects less trivial
    • see optimization in webpack config to turn on/off
  • targets es5
    • default to be conservative to support e.g. old mobile android
  • source maps enabled
    • debugging in chrome+vscode is as easy as pressing F5
    • breakpoints work
  • automatically add import statements
    • via vscode’s feature to automatically add import statements while typing
    • another way to add import statements:
      • my typescript-super-auto-import is included, a script that searches and adds import statements
      • doesn’t rely on vscode
      • makes all the changes at once so it’s very useful after moving code from one file to another
      • automatically removes unused imports
      • to run it, npm run autoimportmodules.
  • integration with vscode
    • hit Ctrl-Shift-B to run commands like lint, prettier, and autoimportmodules
    • line numbers in the output are clickable links
    • there’s also integration with the SciTE code editor; edit a .ts file and press F5
  • development builds with npm start will watch+auto recompiles when source changes
  • es-lint is included and working
  • no need for grunt/gulp, just use the scripts referenced in package.json
    • if you have a script foo and prefoo, npm run foo will run both.
  • prettier is included and working
    • in vscode, install Prettier extension, hit ctrl-shift-p then look for Format Selection
    • confirmed that it is reading our .prettierrc.js
    • another way to run prettier:
      • my prettierexceptlongimports is included, a script that runs prettier on every file
      • it also leaves long import lines on one line as I prefer that visually
      • it also does additional prettying like removing whitespace
      • it also performs stricter checking than es-lint, for example
      • better warnings about using || instead of ??, and long lines in strings/comments
      • to run it, npm run prettierexceptlongimports
  • sass
    • decided to run sass separately, not with webpack’s sass-loader
    • run npm buildstyle or npm buildstylewatch
  • number-to-words as an example javascript+typescript types dependency
    • npm –save install @types/number-to-words
  • serializer.ts as an example typescript dependency
  • csv.js as an example manually added javascript dependency
    • I manually bundle these into external/external_manual_bundle.js for faster build times
  • browser detection via bowser
    • using bowser/bundle instead of the default because we don’t have a babel polyfill
  • includes my tool to prevent dependency cycles
    • it’s useful to have strict layering, modules can only call lower in the list, not higher
    • make sure layers.cfg up to date, then
    • run npm run autoimportmodules
  • code knows if built as release or not
    • use checkIsProductionBuild()
  • code coverage
    • build development, open the site in chrome
    • press F12 for devtools, Sources tab
    • hit ctrl-p, start typing filename you are looking for
    • you’ll see a webpack:// path for it
    • do this for e.g. bwtutils.ts, bwname.ts
    • tab to the source for the ts file you care about and add a break point that will get hit when you run tests
    • hit ctrl-shift-p, then click “Performance-start instrumenting coverage and reload page”
    • run your tests, breakpoint should be hit
    • hit code is shown in blue, not-hit in red
    • retry the steps if no colors are shown or if all colors are in red,
    • it seems to not run correctly sometimes… perhaps because it takes a while to load the sourcemaps
  • default demo confirms that async/await code runs correctly
    • load the page and click the “go async” test button
  • separate tsconfig files for development and production
    • useful for e.g. ignoring unused local variables until building for production
  • my utilities classes are included
    • util512 utils, along with its full unit tests
    • and a simple unit test framework