Having mount as the only required method keeps the entry bar low, and an idempotent unmount is a good call. Two things teams usually run into with import map setups: version drift when two pieces externalize the same library at different versions, and one piece failing to mount and blanking the shell. Does the root project give an error boundary or fallback around a failed mount?
Hello! The mounting project (be it root or not) will always throw any errors during the evaluation of the mount lifecycle chain. The shell blanking is a possibility. Error boundaries are framework things that developers may opt to use, but since they are framework-specific CollageJS doesn't include them by default. Fallbacks are in the same category: Not included because it is up to developers whether to use fallbacks.
Generally speaking, developers/teams should always externalize using the import map entries. The Vite plug-in @collagejs/vite-aim (the hidden plug-in) does this externalization using the root project's import map, minimizing the possibility of errors due to version differences.
Tarun Sharma
Having mount as the only required method keeps the entry bar low, and an idempotent unmount is a good call. Two things teams usually run into with import map setups: version drift when two pieces externalize the same library at different versions, and one piece failing to mount and blanking the shell. Does the root project give an error boundary or fallback around a failed mount?