generated from boboko/starter
Feat: Correctly extracting boboko/core's js
This commit is contained in:
@@ -0,0 +1,26 @@
|
||||
#!/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 "$@"
|
||||
Reference in New Issue
Block a user