With the rise of functional programming in Javascript, it’s increasingly likely that you’ll have come across, or written recursive functions. They allow us to express the solution to a big problem in terms of solving “this one step, plus the solution to the rest”.

If we express that in a more functional notation, it’s akin to fn(x :: xs) = x + fn(xs). This post serves to warn about the limitations of this type of function, and to suggest an alternative for when the situation requires us to exceed those limitations.

This topic came up as part of optimizing tree traversal methods, but for simplicity we will use sum for the examples. The learnings should apply equally to any type of recursive problem, although the runtime constants/impact will vary. Since sum is a single subproblem recursion, we also include treeSum examples for how to handle multiple recursion.

Working with node servers is part of the job. While iterating on such servers, it’s common to go for a solution involving automatic restarts using something like nodemon.

npx nodemon --exec "npm start" --watch src

This will automatically restart the server whenever there are changes to the src folder. But I think we can do better than that!

The restart can be expensive, depending on the kinds of initialization that’s involved. What if we just make node reevaluate only the parts that changed?

Hearing so much about treeshaking in webpack, (and rollup, and parcel), it would seem reasonable that it’d be a well documented type of migration.

The webpack docs have a section on tree shaking, where it looks alluringly simple. We just have to use import { thing } from 'lib'; everywhere, and reap the blessings of the webpack gods.

If, however, we are using plugins like babel in our webpack configuration, (and honestly, who doesn’t?) there are several things that can prevent the tree shaking from working.

TLDR: After a couple days of trying, failing and trying again, the traps seem to be:

• We now want to transpile everything. To process those sweet new esm bundles.
• Don’t transpile module types, i.e. make sure babel doesn’t change esm to commonjs.
• Don’t inject imports via transforms, e.g. polyfills, since it messes with module type detection.
• Don’t mix esm import and commonjs module.exports, they are incompatible.

There are a lot of ways in which developing packages for node can be confusing, especially in an environment where not every contributor is an avid npm package maintainer.

Some common mistakes are easily prevented, and avoiding them will save much time and frustration.

• Is this the correct version of node for this project?
• Are the dependencies installed correctly, with the right versions?

These issues can be solved once and for all with some npm / shell magic.

This post is written for the purpose of covering some gotchas and observations when going back to using Angular 1.x. For reference, we’ll use react components and lifecycles.

This might seem backwards, but has come up when returning to a large legacy codebase.