@dublove creating a "library" of functions is a great idea for your own scripts. It makes it much easier to maintain the functions—if you make an improvement to a function you just change it in that one library file, not every script that you ever put it into. However, if you make a change that breaks existing scripts, for example by changing input parameters or output values the scripts that include it will fail.
The *best* way to include a library of functions will depend on many factors, but I think in your case the best way is a simple
//@include 'path/to/script.js'
Note that #include 'path/to/script.js' is exactly the same as //@include—use whichever you like. If you use VSCode, then use //@include so it doesn't show a linting error.
The //@include 'path/to/script.js' line means that the entire code of script.js will be evaluated exactly as if it had been pasted in to your current script where that line is. This is the simplest way.
There are many other ways, and all solve specific problems, but all introduce issues too. I think keep it simple for now.
- Mark
P.S. just for interest, this is from a job I am working on now:
//@include '../Lib/IllustratorPackingAdapter.js'
//@include '../Lib/PackItems.js'
//@include '../Lib/TrentiumsPacker.js'
//@include '../Lib/Block.js'
//@include '../Lib/Bin.js'
//@include '../Lib/BinPacking.js'
//@include '../Lib/PackingAttempt.js'
//@include '../Lib/BinarySearchRange.js'
Some of these "external" scripts are not very big, but I like to keep them separate. You can include as many as you need.