It depends on your configuration. But first of all it is necessary to remember that Javascript is interpreted by the Navigator, therefore the script must be accessible to all by the web.
If you define a site with the root in the /var/www/site1/html/ folder and try to access a folder in /var/www/scripts using ../../scripts , this should not work. Remembering that the browser opens the web, so it would not even be a valid URL because it would be below the root of the domain.
If you simply set your sites to /var/www and access each one with the folder name in front of the domain, it would work.
I think the question you have to ask is whether it makes sense for this to be structured like this. Whether or not this root folder is going to be part of the internal structure of your site if you use it as such.
Do sites 1, 2, 3 have any relationship to each other or only share these javascript libraries? And everyone has his domain?
What new problems will this config cause? (if you are going to migrate for example, it will be more complicated).
You could have a working folder with Javascript (where you modify them) and have an installation script (Bash or Makefile) that copies / replaces the files to the sites (all or only one of them) and then an arrow permissions / user.
In this case, I would use something like make site1 or make all to copy.
So the whole site would still be contained within your folder, but it would be easy to update. I think it would also be easier to test these libs before installing into production as well.
In fact, scripts only need to be visible on the web for your access page. But using scripts from other domains is often blocked by browsers for security reasons.
Another option would be to release the use of symlinks in apache or nginx. By default this option is usually turned off for security reasons, because with this connection it is extremely easy to publish / access any server folder on the web.
To avoid using symlinks, you can use hardlinks (non-symbolic links), which basically duplicate the files, but keep the same inode on the disk. So the files will remain unique, but will have more than one reference in the disk tree. Pretty complex to maintain and not usually recommended unless you have a real reason for it.
The biggest problem is keeping a point of failure so critical for so many systems.
Any problems with this folder and all sites will suffer.
Working as a installable repository avoids all these issues and allows you to work more peacefully in a testing environment.
