Though the question is a bit unclear, but assuming you want to list packages installed in your system that have systemd mentioned as Depends on,
you can simply check that by pacman(since you are in manjaro).
pacman -Qi systemd | grep Required
In my case, it shows the following:
Required By : android-udev at-spi2-core base bluez-utils colord dhcpcd dunst iio-sensor-proxy libcolord libgudev libinput libmbim libpulse libwacom mdadm media-player-info mkinitcpio netctl phodav polkit rtkit sbupdate-git subversion swayidle systemd-sysvcompat transmission-cli upower vte3 xdg-desktop-portal zram-generator
Does it means i would not be able to use these programs without systemd? NOT necessarily.
I am on arch and both arch and manjaro provides official support for a systemd based system. That means, the binary packages(that requires an init system, udev,syslog etc) in the official repositories are packaged keeping that in mind. Systemd fulfills these roles and hence if an arch package necessitate ( not really) the packager would mention systemd as a dependency in the PKGBUILD.
Let's take some example, in my case you can dhcpcd is listed as being dependent on systemd. That is for convenient, it doesn't really require an init system to start. you can just run from the terminal dhcpcd.
The package maintainer has packed some systemd services with it so you can start dhcpcd with systemctl or have it launched by systemd after boot ( the same can be easily accomplished by a shell script run from your ~/.profile or other autostart script).
Another example is the libinput.libinput requires udev and udev is provided by the systemd package hence systemd is given as a dependency. artix have eudev and so official packages are packaged with eudev in mind.There are other alternatives to udev like suckless's nldev or mldev and it would only require few tweaks in a text config file to adapt to these different environments.
netctl(network manager) is listed as well, but i never needed to start it with its systemd service.I could just start it from ~/.profile(for example).
These are not hardcoded in the program code. The only difference ( from a layman's perspective ) is that different service manager uses different configuration syntax and location to store them.
Here's an excerpt from gentoo wiki. Meant for gentoo users but you get the idea:
Some upstream packages provide systemd unit files, to make them easier to install on systemd-based distributions and try make them work mostly out of the box, but don't otherwise have any heavier integration with systemd, or require any systemd-specific functionality. This sort of packages are not considered to have an actual dependency on systemd (neither 'soft' or 'hard'), and, according to the official ebuild policy for systemd, unit files follow the usual guidelines against small text files (bash completion, logrotate etc.) and ebuilds must not prevent their installation based on the systemd USE flag.
and
Unit files are harmless and do nothing if systemd is not installed, just like OpenRC service scripts do nothing if sys-apps/openrc is not installed. However, users that absolutely do not want systemd unit files on their machines, can add systemd's unit file paths to the INSTALL_MASK variable in /etc/portage/make.conf:
So, it is not that your packages(that are packaged for systemd) would break if you change from manjaro to artix, it is just that artix package maintainers would package their packages keeping their implementation in mind so there's no question of breaking anything generally.
even for snap,AFAIK, it requires systemd-tmpfiles to create and delete temporary files as well as for mounting the snaps/squashfs with systemd.mount. It is possible to detect those calls to snap and replicate that with your own custom scripts as this guy did
However
There are indeed some packages that may have hard dependencies on systemd or some of its services like Gnome desktop environment which depends on systemd-logind. But artix has a gnome-openrc iso in its testing (alpha ) stage .
