ee-cdn-cli finds your output folder and keeps .git out of what it publishes

This release of ee-cdn-cli takes some of the setup out of publishing a site, and is stricter about what goes into the bundle it uploads.

It finds your output folder

You can now leave the folder off the command:

npx @evolving-edge/ee-cdn-cli --domain www.example.com --project proj_…

The CLI looks at your project, works out which generator built it and where that generator writes its output, and tells you which folder it chose. It recognises Astro, Next.js (static export only), Nuxt, SvelteKit with the static adapter, Docusaurus, VitePress, Gatsby, Hexo, Eleventy, plain Vite, Hugo, Jekyll, MkDocs, mdBook, Sphinx and Zola.

It refuses, instead of guessing, when it finds no generator, when it finds two, or when the folder it would use has no index.html. Naming the folder yourself still works exactly as before.

Routing options as flags

--trailing-slash and --clean-urls turn on the trailing-slash rule and clean URLs by writing the matching line into your site’s _redirects file before packaging, creating the file if there isn’t one. If your own file already sets the option, your file wins, including when it says off, and the CLI warns you. It never reorders your rules, and it says what it did.

In the Astro integration, deploy.trailingSlash does the same and is on by default, so an address like /about arriving from elsewhere redirects to /about/ instead of returning a 404. Set it to false to leave _redirects alone.

Pin the builder version

The CLI downloads the builder that packages your site. --builder-version, or the EE_BUILDER_VERSION environment variable, now pins which version it uses, so a build in CI packages the same way every time. A pinned version that doesn’t exist gets a plain error. We recommend pinning, together with a committed lockfile, for CI.

Claim a custom domain from the command line

The package now includes a second command, ee-domain, which claims, checks and verifies a custom domain without opening the portal. It does the same job as the portal’s Custom domain block, and the same rules apply, including the 48-hour limits described in the custom domains entry.

• Use a deploy token scoped to the project that owns the domain. It can manage that project’s domains and no others. Global deploy tokens are refused, and from 0.3.1 the error says which kind of token to use.
• Through npx, name the package. The package now holds more than one command, so ee-domain has to be asked for explicitly:

npx -p @evolving-edge/ee-cdn-cli ee-domain claim …

The deploy command is unchanged: npx @evolving-edge/ee-cdn-cli … still deploys, as before. Custom domains in the docs has the full steps for the records to add.

What’s left out of a bundle

• .git, .hg and .svn are never packaged, whatever your configuration says. Until now, a folder that contained one was published with it, which for a full checkout means the site’s whole history. This protects sites built from this release on. If you have ever published a folder that held one of these, deploy again with this release.
• .DS_Store and Thumbs.db are left out unless an include pattern names them exactly.
• Everything else is kept, including .well-known/, .nojekyll, _redirects, _headers, .gitignore and .github/.

Each build prints a line saying what it left out.

Symlinks

• Links inside the site folder are followed. A deploy of an output folder that is itself a link, as Nuxt’s dist is, used to fail. It now works, and so do linked folders inside the output.
• Links that point outside the site folder stop the build, with an error naming the link. Until now a linked file was followed wherever it pointed, so a link to a file elsewhere on the build machine would have been published with the site.
• A link that loops back on itself is an error, not a hang.

Content types

The type recorded for each file no longer depends on the machine that built the site. Fonts (.woff, .woff2, .ttf, .otf), web manifests, source maps and Pagefind’s search files now get the right type. Files already deployed keep the type they were built with until the site is next deployed.

Renames get a new address

A site’s address in storage was worked out from the contents of its files but not their names. A deploy that only renamed files could keep the old address, so nodes that already held the site went on serving the old paths while the new ones returned 404s. File names now count.

Limits

• Every site gets a new content hash on its next deploy, once. Nothing needs migrating, and sites already deployed keep working as they are.
• The builder is now published for Windows and Intel Macs, but hasn’t been run on real machines of either kind. If it fails for you there, tell us.

What you need to do

Update ee-cdn-cli and deploy as usual. If you have ever deployed a folder that contained a .git directory or a link to a file outside it, deploy again with this release so the new bundle leaves them out.