generated from boboko/starter
27 lines
1.3 KiB
Bash
27 lines
1.3 KiB
Bash
#!/bin/sh
|
|
set -e
|
|
|
|
# Mirrors entrypoint.sh's Composer block: node_modules is a named/anonymous
|
|
# volume, not the bind-mounted host directory, so this container needs its
|
|
# own live install on every boot rather than relying on whatever was baked in
|
|
# at image-build time.
|
|
echo "[entrypoint-vite] Installing npm dependencies..."
|
|
npm install
|
|
|
|
# Re-resolve @boboko/core specifically on every boot, whether it's a local
|
|
# path-repo checkout (file:../boboko-core, needs docker-compose.core-dev.yml's
|
|
# ../boboko-core:/boboko-core mount) or a tagged VCS install
|
|
# (git+https://...#vX.Y.Z) — the same manual toggle composer.json's
|
|
# repositories/_repositories block uses for the PHP side of this same
|
|
# package. A plain `npm install` above only installs what package-lock.json
|
|
# already pins; it won't notice a new commit on the path-repo checkout or a
|
|
# re-pushed tag. `npm update` re-resolves that one package against whatever
|
|
# package.json currently says and rewrites package-lock.json to pin it —
|
|
# exactly like `composer update boboko/* --with-all-dependencies` rewrites
|
|
# composer.lock, which is committed so prod picks up the resolved version via
|
|
# `npm install` alone (no `npm update` in prod's build).
|
|
echo "[entrypoint-vite] Re-resolving @boboko/core..."
|
|
npm update @boboko/core
|
|
|
|
exec "$@"
|