Deploy while keeping a consistent and complete ./dist/?

[Martien]

If I understand correctly, npm run deploy removes ./dist/, creates a new one, and then creates – index/copy/build/render – all static files.

During deploy, ./dist/ is incomplete, causing serving from ./dist/ (e.g. using Apache) to break.

I now work around this by copying the ./dist/ to a specific directory, and then symlinking (ln -shf …) to that version when ready, and removing the previous version.

This feels somewhat redundant.

Is there a way that npm run deploy gets that built in? That is, deploy silently prepares a new dist, and, when successful, serves the new version, deleting the old.

Or are there better ways to tackle this?

[mootari]

deploy is a shell command in your package.json that you can change to fit your requirements, or you can add your own script to run instead. The name itself is just a convention, there's no hidden functionality attached to it (i.e., it's not a lifecycle hook).

[Martien]

Thanks for your reply.

I’m fairly new to npm. Therefore, I have trouble finding this deploy shell script, let alone modifying it to my needs.

I do not want to deploy to Observable (yet), but to my own subdomain, served by my Apache httpd. So I need an instance of dist in the appropriate place. I thought I could simply use a symlink to dist, but this disrupts the vhost for a little while during npm run build.

So I created a shell script that rsyncs the dist to the appropriate document root of Apache httpd and ln -sfh to the new version.

[mootari]

Therefore, I have trouble finding this deploy shell script, let alone modifying it to my needs

As mentioned, the command is defined in your package.json file. I don't want to go into further detail on using scripts, but you should be able to find plenty of resources online.

I do not want to deploy to Observable (yet)

npm run deploy (which invokes observable deploy) is intended for deploys to Observable Cloud. If you want to deploy to a different platform you'll have to run observable build instead and then move the files to their target destination.

You cannot override the output dir directly through the build command, but you can specify a custom configuration file (see observable build --help for details), which could look like

// observablehq.my-deploy-config.js
import config from "./observablehq.config.js";

export default {
  ...config,
  output: "some-temp-dir"
};

Edit: See my answer below for a simpler approach.

[Martien]

Yes, this is how I understand it, too.

However, changing output does not solve the output-is-unstable-during-build problem.

Anyway, my current solution using rsync to copy dist to the desired location and then ‘throwing the switch’ by using ln -sfh works for me.

[mootari]

Actually, an even simpler solution than what I suggested above is to just specify the output dir in your config via an environment variable:

  output: process.env["OUTPUT_DIR"] || "dist",

and then invoke build like

OUTPUT_DIR=my-temp-dir npm run build

Edit: To clarify, the usual workflow for symlinked webroots is to use folder names that include either the git revision or deployment timestamp, and then update the webroot symlink to point to the new folder. This also allows you to roll back in case of problems.

[Martien]

Exactly! That is what I imply when referring to ln -sfh.

My script does exactly that:

# !run from project directory!

# assumes ./dist/ has release to deploy

date=`date  '+%Y-%m-%d-%H-%M-%S'`
www='/somepathtovhostrootdir'
dest="${www}/${date}"
obsolete=`readlink ${www}/www`

echo "date: ${date}"
echo "www: ${www}"
echo "dest: ${dest}"
echo "obsolete: ${obsolete}"

[ -d "./dist" ] || {
    echo "./dist does not exist"
    exit
}

[ -d "${dest}" ] && {
    echo "${dest} already exists"
    exit
}

echo "installing: rsync -a ./dist/ ${dest}"
mkdir "${dest}" &&
rsync -a "./dist/" "${dest}"

echo "${date} installed"

cd ${www} &&
ln -shf "${date}" www &&

echo "${date} activated"

[mootari]

During deploy, ./dist/ is incomplete, causing serving from ./dist/ (e.g. using Apache) to break.

Can you elaborate how this would be relevant when deploying to Observable?

[Martien]

I don’t know. I have never deployed to Observable – apart from a simple experiment with the default demo env.

If I would, I still need my own domain. That is, not something like https://martien.observablehq.cloud/martien/, but more like aarde.aardrock.nl (which may even change in some day).

Also, I understand that on-premises comes at a price (contact sales). As my endeavour is small scale, non-commercial, non-critical, I think this path is not fitting for me.