How-to: create a standalone eleventy binary

[aral]

I just made a little time to start playing with eleventy and wanted to see how easy it would be to package into a single binary to ease distribution. Turns out – very easy (with one niggle, see below):

1. Clone eleventy repo

   git clone https://github.com/11ty/eleventy

2. Install Nexe:

    npm i -g nexe

3. Compile eleventy:

   nexe -i cmd.js -o eleventy --resources=src/Engines/*

4. Move eleventy somewhere on your system path (e.g., on Linux):

   sudo mv eleventy /usr/local/bin
   

That’s it. Now you can run eleventy as usual. The difference being, you don’t even need Node or npm installed to do so. (The resulting binary on my machine was 97MB uncompressed, 29MB compressed (.tar.gz).

The one niggle I noticed is that live reload does not seem to be triggering for content markdown files (it does work on other files, for example, for njk layout files). Haven’t had time to look into why.

Not sure if you want to provide compiled binaries as it seems (from a cursory glance), npm is pretty much required for working with eleventy (e.g., plugins, etc.) so please feel free to close if not useful.

[DirtyF]

Interesting, did you notice any significant change on build time?

[aral]

@DirtyF No difference in render times and no discernable difference in startup times (maybe a tiny 1/4-1/2 second lag on the compiled version… but nothing that stands out).

[danfascia]

This is actually quite a useful discovery because sometimes I have the need to use 11ty as an embedded system in my medical environment so I can truly see a use case for this where node_modules are frustrating.

[aral]

@danfascia I went a little further and spiked a quick integration with Site.js but I’m blocked at the moment by this merge request (see this issue) making it impossible to include Eleventy in any app that accepts a path to operate on (the merge request limits Eleventy to running only within the current working directory).

I was able to integrate Hugo into Site.js for the next release (it was trivial as it is a single binary and can operate on any path) but this is going to block me from potentially integrating Eleventy also (which is sad as I like what I see so far).

[zachleat]

@aral What is the specific blocker? Work for #368 has not been merged into Eleventy. #376 did not include any restrictions to the site output target, afaik

[aral]

@zachleat Ah, thanks for the clarification, I was confused, sorry. Apparently there are bugs in Eleventy’s path handling in general which I’ve now been able to reproduce using the eleventy-base-blog project and eleventy installed via npm. Will file a separate issue for that.

[aral]

@zachleat Just opened issues #937 and #939 which can be trivially reproduced using the eleventy-base-blog project and eleventy installed via npm.

There’s also #938, which seems related, but will be very difficult to reproduce as it relies on certain files on my machine (but hints to a behaviour that shouldn’t be exhibited).

Hope these help. Would love to hear your thoughts when you get a chance.

[Ryuno-Ki]

Thanks for the research, @aral.
I was wondering, whether somebody asked for packaging for GNU/Linux distributions?
For example, Debian or Arch Linux.
Perhaps they could use your findings in the process?