I doubted it too, until I saw it and could come up with no other explanation. I don't think it was a full parse, just something like a dumb grep for certain patterns. It threw errors trying to import something that was only mentioned in a comment, and removing the comment fixed it. I wish I could find the bug report.

It's quite possible they did do that. For example, Angular parses your source to perform Dependency Injection based on argument names.

Well thanks for that. Now I know what not to use.

To be fair, that was a fallback and was used only if you didn't annotate your dependencies, which is what Angular expected you to do.

That's AngularJS released in 2010.

Angular 4 is TypeScript and therefore much less hacky.

it is possible to read comments on runtime in js and do things based on what you read with a while loop + if else

ExtJS required a custom build system (sencha) so it’s possible it’s related to that.

This would be my guess as well. I worked on a ExtJS project (v4.0.7 or so), we didn't use the sencha build tools, but when I started there we had a bash script which was a 7 iteration sorting "algorithm" that used grep to try and match the `requires`, `extends`, `model` properties to determine dependency order. It too also uses commented out code or documentation of usage, as they were the first lines it saw. I still do not understand how it worked for so many years. The first thing I did was build a deterministic dependency ordering build tool using esprima.

It didn't require it; it was optional depending on how you used ExtJS. In a project I worked on we simply had the minified, master extjs.min.js file included and then we simply referenced and used that.

I don't remember how the build stuff differed but it wasn't required (though I'm sure there was a benefit to using it).

OK, so what's your explanation?

OP is confused.

I wish that I had been confused, it was an appalling thing to find. Basically, it was an interaction between the template system (https://docs.sencha.com/extjs/6.5.0/modern/src/Template.js.h...) and their dynamic class loader (https://docs.sencha.com/extjs/6.5.0/modern/src/Loader.js.htm...). The template system used regexes to look for JS expressions to evaluate inside HTML templates and then tried to figure out how to supply them with values. I had some /very/ complicated templates and IIRC it picked up on some commented out bits and ended up triggering the loader's dependency resolution. Again, I'm not saying it was running like a babel-style parser in the browser - it was just regexing for certain expressions and dynamically loading classes based on the results.

I saw a similar behavior in their binding formulas, I noticed the formula method would never get called unless you had used a "get" method inside of it. This may have been documented, not necessarily a bug - but it made me think they were scanning the source code at run time to figure out which events to observe.

*Note: Not sure which version this was.