How to use relative paths in JS's new `require()`?
Nov 16 2014 | 8:39 pm
You can see test code here!
I have a lot of files in hierarchical subdirectories, some of which depend on each other. For my application at least, I'd prefer that all includes be relative to the original "top-level" .js file, wherever that may be.
- Nov 16 2014 | 9:02 pmNot in front of Max right now, but you could open the toplevel js (needs to be inside the search payh) with the file object, read its parent folder and store it as a base path for the includes/requires.
- Nov 16 2014 | 9:17 pmThat seems suboptimal (no insult intended at what seems to be a possible "good hack"). ;-)For one thing, aren't we getting away from the search path with Max 7?Much worse is that I'd have to copy all that code into each file that included another .js - which is at this moment is 85 .js files (though not all of these are current). That's an awful lot of duplicated code...Relative paths are required by the CommonJS spec, so it's quite likely that this is an oversight that will be fixed in an upcoming release.(EDIT: I also realized that the CommonJS spec indicates that you can and should omit the .js in the filename, and that doesn't seem to work either. These things happen - it's early days yet! :-) )
- Nov 16 2014 | 9:39 pmI get your point. Have you tried just the filename (without path)? If your code is part of a package maybe they are recognized?
- Nov 16 2014 | 9:41 pmoh just saw you tried filename only. but are they part of a package/in the search path?
- Nov 16 2014 | 10:07 pmThe code sample has a list of all the possible paths I've tried - and I uploading three possible files too.So I did quite a bit more testing here and did find one case that works - but I found another "feature deficiency" as well. ;-) (This is all on a vanilla Mac OS/X 10.9 "The Decider" "Mavericks".)Basically, anything involving loading .js and subdirectories doesn't work.First, your .js file has to be in the same directory as your .maxpat file. If you save the .js in a subdirectory, it will not be found when you close and open the patch again. (This worked fine in Max 6.)If you open the .maxpat in an external text editor, you can see that it does seem to know about the subdirectory, but the actual JS when you close and reopen the box becomes blank.Second, any require statements you use must also reference files in that same directory as your .maxpat file.This kinda works, but my library has 113 .js files and over a dozen subdirectories so "throwing them all in the same directory" is a suboptimal solution.As I said, these are very early days in Max 7 and you expect such glitches. The CommonJS spec requires relative paths to work, so I'm highly confident that this will get fixed at some point. I'm hoping also to again be able to use .js that's not in the same directory as the .maxpat. :-)Thanks for reading!
- Nov 16 2014 | 10:28 pmOh, didn't get that last comment till after I finished. Good suggestion!The patch wasn't in the path initially, but I made sure to add it to the path and restart. No change!
- Nov 20 2014 | 12:22 amYes, just with the difference that packages are always included in the search path (including subdirectories). You don't need to add them manually. You are right about the CommonJS specs, but i guess it's a conceptional point of view if this is a "bug". The Max path paradigm is simply different from the one of common JS: To load an abstraction or object the filename is the only reference (same for files loaded into [js]) therefor the filename has to be unique.Under this paradigm there is no relative path. It would be interesting to hear what Cycling '74 thinks about that. I'd say the way it is implement now is coherent within the Max paradigm and therefore the CommonJS paradigm is implemented only as close as possible.If it would be implemented strictly that would make things with Max more confusing: Think about an abstraction that uses a JS script from a package: as soon as the location of the abstraction would change (which it can according to the Max approach) the include/require functionality might break.Lots of words ... :) in short I would be surprised if it changes.It's the same for the file extensions: within Max js files can be loaded with and without .js. Therefore it makes sense to stay closes to the Max specs and to make it optional.
- Nov 20 2014 | 12:28 amThink about an abstraction that uses a JS script from a package: as soon as the location of the abstraction would change (which it can according to the Max approach) the include/require functionality might break.well, that's wrong :) the location of the loaded js would be the root...
- Dec 16 2020 | 4:33 pm6 years later, I am running into the same issue. Does that mean that Jan's point of view was indeed shared by Cycling '74 and require does not support a module hierarchy? Everything must live in a single directory, and filenames should be unique?