Dependency and Portability Tradeoffs

Every dependency buys something.

Every dependency also becomes something your project must continue to resolve, build, and deploy.

Four questions before adding an extension

1. What problem does it solve?

If the answer is "I saw it in a tutorial," stop.

2. Can Jekyll already solve the need clearly?

Maybe Liquid, data files, collections, layouts, or a small amount of CSS already cover it.

3. Does the deployment environment support it?

A local plugin that cannot run in your GitHub Pages deployment path creates a portability gap.

4. What happens when it changes?

Consider:

• version compatibility;
• theme overrides;
• plugin APIs;
• generated markup changes;
• security/update maintenance.

Portability model

SOURCE REPO
+ GEMFILE/LOCK
+ JEKYLL VERSION
+ THEME VERSION
+ PLUGIN VERSIONS
+ DEPLOYMENT ENVIRONMENT
= REPRODUCIBLE BUILD

Remove one assumption and the project may still build — or may not.

Controlled comparison

Choose a feature you could implement two ways:

• hand-written Liquid/data;
• plugin;
• custom theme source;
• theme-provided behavior.

Compare:

Checkpoint

Write one sentence beginning:

I am willing to add this dependency because...

and one beginning:

I am not willing to add this dependency because...

Use technical reasons, not vibes.