Tools

  • Semantic release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package. This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification.
  • Editorconfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.
  • GitHub courses
  • mkcert
  • iTerm2
  • fish
  • Practice Emmet:
    • Childs
    • Siblings
    • Climb-up
    • Multiplication
    • Item numbering
    • Grouping
    • Id and class

vim

  • vimcasts
  • Understand indentation and tabs
    • tabstop: width of a tab character
    • expandtab: set to use spaces instead of tab chars
    • softtabstop: set to fine tune amount of whitespace to be inserted
    • shiftwidth: amount of ws to insert or remove using indentation
  • commands in normal mode

VS Code

Browser Devtools

nnn

tmux

Daily practice

  • Read and study Clean Code
  • Read and study The Pragmatic Programmer
  • Learn about CI tools and workflows

Version control

Understanding upstream

GitHub tells you to use git push -u origin master. This SO answer gives some insight into what upstream is and why that is required.

Some of my takeaways:

  • An upstream is simply another branch name, usually a remote-tracking branch, associated with a (regular, local) branch.
  • Each branch can have 0 or 1 upstream.
  • Setting an upstream is convenient becaues then many git commands can be used without arguments to produce expected results (i.e. fetch, merge, rebase, pull, status)
  • push = fetch followed by merge or rebase

JavaScript module and package managers

  • Understand and write about npm, npx, ncu, package.json, etc.
  • Understand npm audit results
  • Understand how to create a package.json from scratch
  • yarn workspaces and monorepos
  • Check out Pika. Pika's mission is to make modern JavaScript more accessible by making it easier to find, publish, install, and use modern packages on npm.
  • Lerna
  • Check out yalc. Better workflow than npm/yarn link for package authors.

Publishing on npm

This article from Freecodecamp goes over the least possible work from zero to published package. In summary:

  1. Put your code inside a folder. The package.json in that folder should have a name and version at the very least.
  2. Create an account on npm and log in using the command line: npm adduser or npm login.
  3. Publish with npm publish or npm publish --access=public if you've used a scoped package name, since scoped packages are published privately by default (and you need a paid account to publish privately).

Some additional notes:

  • Those steps will get you from zero to published, but there's a bit more that you'd typically want to do: add a README, a LICENSE, more fields to the package.json files, badges to your README file, an .npmignore file, etc.

  • Understand semantic versioning so that you can assign versions correctly. Note that you can use npm version [major|minor|patch] to update your package.json from the command line. The command has more options, check them out.

  • Understand package scoping in case you want to use that feature.

  • Understand npm dist-tag and how to use npm publish --tag=<tag-name>. When you publish, npm puts that new version on the latest tag by default. If you're maintaining different major versions of your package, this could create problems for your users. If you publish a patch for your 3.x version, your users will install that instead of your latest 4.x. Learn how to use tags to manage this. You could have next for a 5.x work in progress, latest for your stable up to date 4.x work and 3.x-latest for maintenance.

Developing an npm package

The short version: use npm link. But if you need to test preinstall/postinstall hooks for your package, npm link won’t run those hooks, so you do:

bash
npm install /absolute/local/path/to/your/other/package

Note that npm link creates a symlink to <your-package> in the global space, and then when you call npm link viking from <your-project>, it creates a symlink not directly to <your-package>, but rather to the global symlink. This is an important differences if you are using different global Node.js versions, e.g., NVM. npm install /absolute/path/viking will alter package.json, npm link does not.

Check out Lerna, a tool that optimizes the workflow around managing multi-package repositories with git and npm.

Resources and assets

Bundlers

In the context of web applications, bundlers are tools that transform your source files to make them optimized for deployment. I think that mainly means smaller size and less network requests, but it also includes things like managing the transformation of things like SASS (good to have in development) into CSS (required in deployment).

These are some popular bundlers:

Here's a comparison of Webpack, Parcel and Rollup. I'm currently debating myself between Webpack and Parcel. Webpack is everywhere, but Parcel seems to provide a better DX. I think I'll try to focus on Parcel for now and be ready to move to Webpack depending of how they both evolve.

Some of the features to understand bundlers:

  • Configuration. I honestly don't see what the big deal is, but it is nice to have as zero-config as possible. It seems Parcel provides the lowest config requirement.

  • Entry points. Where does the bundler start parsing to do it's thing. I like that parcel provides an index.html entry point out of the box.

  • Transformations. SASS to CSS, for example. Added with plugins. Again, Parcel seems to handle the most without plugins.

  • Tree shaking. Eliminating dead code. Not supported by Parcel yet.

  • Dev server. Watching for changes to your source files and automatically rebuilding your bundles.

  • Hot Module Replacement (HMR). Being able to reload parts of your running app without having to reload the whole app. Speeds up development.

  • Code splitting. Creating bundles that are broken up into different parts. Improves UX by requiring a smaller initial download. The user can start using the app while the rest of it is being fetched in the background.