Jahed Ahmed

FrontierNav Weekly: 16 November 2020


Support the project

This week, FrontierNav has 1 new anonymous patron!

If you would like to support FrontierNav, please consider donating on Patreon. Doing so helps fund development and keeps the project going. Thank you.

Dependency Hell

The past week was a bit of a drag. It seems a lot of software and services have decided to release major updates in the last 3 months of the year. Companies are also updating their Terms & Conditions. There are a number of lessons to be learnt from this, some I've acted on from previous experiences, some are still causing issues.

JavaScript Tooling

The hardest part with major version upgrades is coordinating them and keeping track of progress. Webpack for example has multiple plugins that haven't been updated for Webpack 5 yet. React 17 needs TypeScript 4.1 for the new optional JSX API. PostCSS needs to wait for postcss-preset-env which itself needs to wait for a ton of other plugins.

A lot of these projects are too large and complex to learn and send patches for without significant time investment. Projects like Webpack, Babel and React are well funded, but some, especially the plugins, aren't. So there's no reason to expect them to be kept working and up-to-date.

The only way to reduce this problem is to reduce the number of dependencies to a manageable level, make sure they're actively maintained and to keep configurations close to defaults. Any non-critical dependencies should be optional. That is, if they were removed, that feature may be disabled, but everything else should still work.


Firebase's JS SDK is one the most painful dependencies I have to manage. Their TypeScript definitions may introduce breaking changes but none of it is documented. The WebSocket API isn't documented either and can be hard to debug. Their repository has failing checks but they still make new releases. I don't know what their process is but it's been unreliable.

It's gotten to a point where I've slowly moved Firebase into its own wrapper so that it does minimal damage when it doesn't work and regressions are easy to discover. This low-trust approach is something I've adopted over the years for most complex dependencies where runtime scenarios can be unpredictable.

Even with these issues, I still think Firebase's conveniences makes it worthwhile. I don't need to maintain any network APIs, security, databases, authentication flows or middlemen. Since it handles so much, I can understand why it can feel so brittle.

OAuth Providers

On top of code dependencies, companies like Facebook and Google are constantly revising their legalese. I've stopped renewing third-party integrations at this point. Facebook logins might stop working in December. Other providers may also stop working in the future. Email logins will continue to work, which is why I added that alert a few weeks back to ensure people have a verified email address.

While using third-party OAuth providers reduces friction in signing up and logging in, longer-term is creates an unfair dependency between a developer and a giant megacorp. Where the megacorp dictates the terms for continued service and the developer has no say. Passwordless, email-driven logins using single-use links are a good middleground but of course it won't beat the convenience of a one-button flow. I'm okay with that.

Next Up

I'll be taking a break from FrontierNav next month. I'm at a state where most of the features feel good enough. Any polish I do ends up feeling insignificant. It's a chance to come back with a clear mind, take a good look at the last year and see where to take FrontierNav next.

Thanks for reading.