JS require still isn't CommonJS compatible - doesn't understand paths!

Hey Tom,

I'm just starting to use this functionality myself, but I think that in regards to (1), this isn't an issue if the files are in Max's search path. All my files are organized as a package and in ~/Documents/Max 7/Packages/, and I have no trouble pulling a require() from different subdirectories inside that package. There might be other problems (just getting started here), but both require() and include() seem to work from inside a package.

(Perhaps this isn't even what you're talking about, though.....)

a

Interesting suggestion!

I could do that, with some changes to the code, but I'm trying to write a library that others might use (there are a couple of people who actually do already).

As such, forcing my poor users to have my 137 .js files into the classpath in order to run it is like leaving a lot of boobytraps lying around. Some day, some .js file name of mine will collide with some other .js file somewhere, and someone will be left trying to debug it - and worse, there might not be a good solution without editing my project (which means they have to apply that edit again every time I make an update).

The possibility of collisions isn't at all hypothetical - because the project already has ten files named test.js (and there's a good reason for it - when I create unit tests I create a file named test.js that loads the tests for that directory).

I was also very much hoping to start using third-party CommonJS libraries - because there are a lot of them, and some of them are extremely useful and high quality. And many of these also rely on relative paths working correctly.

For documentation purposes, this is also a bad idea. When someone sees require('controller.js'); they really have no idea where that file is. require('swirly/softstep/controller.js'); is so much clearer to read.

I understand that I likely have a different outlook to most of you, as I've been making a living as a programmer for about 35 years, and in those 35 years I've seen every possible mode of failure you can imagine - and I've also read a lot of incomprehensible code that no one could maintain after its creator left. As such, I consider correctness and clarity to be of supreme importance.

For example, I might be the only person in the world writing Javascript unit tests for Max/MSP! On the other hand, I have a complex setup with text score files in JSON which dynamically load handlers for MIDI as the performance goes and it has so far never crashed or failed during live performance...

I refuse to cut corners - because cutting corners is just never worth it in the long run, because debugging is stressful and difficult. And I won't accept an "implementation" of a standard where important parts simply don't work.

The correct way to organize a large Javascript library is to use subdirectories and relative includes. CommonJS requires that you support paths in your require statements, so if you don't, what you have is not a CommonJS implementation.

I completely understand your point of view, and agree with it....but I'm also tickled pink to have ANY sort of include capability aside from js-extensions. Hopefully we'll see some improvements in implementation in the future, as all of your points are completely valid.

a

yea, would be nice to have it commonjs comlient... but as I wote in an earlier discussion: The Max search path paradigm collides at some points with it. abandoning search pathes just for require doesn't seem to be a good idea. it's too deeply rooted in Max.
One way would be to add a comment attributes (java style). i.e.

/**
* @CommonJs
*/

could indicate to only use pathes in require() and include();

introducing a new system of flags doesn't seem to be slick though. on top of it it would be nothing that is common in JS.

the existing system with js-properties like
autowatch, inlets and similar woud break the code outside Max.
and without any extra flag there are problems with detecting the difference between
require(test) and require(subfolder/test).
while the second one is clear, the first one will remain ambigous.

How does the File Object handles this case? it supports relative/absolute paths as well as Max search path... Don't remember...

Max Js implementation is much older than common js, and that's where we are hitting a wall.

> Max Js implementation is much older than common js, and that’s where we are hitting a wall.

I'm not sure this is true. I'm pretty sure I remember that Cycling74 didn't actually write their own Javascript from the ground up - that would be far too much work - they used an open source one, I believe Mozilla's.

they do, but what i meant is : when the [js/jsui] api was created, code still was pretty procedural and modual approaches in js werent at the horizon.

An option could be using a grunt task to combine all js files into one. So you get automatic recompilation, have your seperated js files for single development and unit testing and use the single big file for deployment. But that may only help with a specific organization of code and may limit elsewhere as you pointed out with libraries... But having a grunt server runnning that rebuilds on File Change may be more convenient than a manual triggered make....
I found organizing everything in packages helpful too.

Tom actually has its own "combiner" that concatenates js files already . The thing is to avoid that process at all due to several maintaining circumstances , especially now when CommonJs approach was considered recently in the new Max .Would love to have it implemented properly as suggested here . But if Jan is right with his observation then , that is sad honestly .

+1