Earlier quoted context omitted.
How is that any different from build tooling for any other language? On my system, gcc with a bunch of commonly used dependencies requires just about the same space (and it's a full Linux system, not a trimmed down container).
> How is that any different from build tooling for any other language? On the one hand yes, on the other hand it's a large amount of crap just to build a static site. `npm install @11ty/eleventy` pulls 600 packages and yields a 100MB node_modules folder. Even Sphinx (whose scope goes way beyond static site generation) "only" pulls in about 75MB worth of stuff (a third of that being Babel) over two dozen dependencies…
Shrinking my static site
21–30 of 107 posts
Re: Shrinking my static site
#22https://github.com/gunjank/docker-nginx-scratch/blob/master/...
Re: Shrinking my static site
#23Same also applies to even Java. Maven downloads tons of stuff these days. You may only be using single static string from a dependency.
Re: Shrinking my static site
#24Naturally this lead to me gaming the system and making my docker images as in RAM usage small as possible. In the end I even abandoned SSH as too heavy and switched to shadowsocks (2MB resident) for networking the docker instances together.
Re: Shrinking my static site
#25He doesn't tell whether there have been any build time improvements after the changes to the Dockerfile. Will the builder docker images get cached and thus reduce the build and deployment time?
Re: Shrinking my static site
#26> This docker image resulted in a 419MB final image and took about 3 minutes to build. There are some obvious issues with this. For instance every-time I change any file it must go through and reinstall all of my node_modules. He doesn't tell whether there have been any build time improvements after the changes to the Dockerfile. Will the builder docker images get cached and thus reduce the build and deployment time?
Basically the main step is the COPY . . step (previously COPY . /app) which will invalidate the cache every change to the code.
Also that on the builder, the steps beyond npm run are not needed, but well they won't improve much on the performance or space of the overall process.
Re: Shrinking my static site
#27Static site and docker shouldn’t be seen together.
Re: Shrinking my static site
#28I use Hugo as my static site generator, single binary, no dependencies, generating hundreds of pages in milliseconds ... so reading this feels so wrong, I want to call it JavaScript masochism. Taking a simple concept like a static site and adding a ton of complex tooling around it because it is the trend now? Why would you even need a docker image to run a static website? The best thing about a static website us you…
Re: Shrinking my static site
#29Static site and docker shouldn’t be seen together.
Re: Shrinking my static site
#30how about good old ftp and a cheap shared webhost? like its been done for 30 years.