requireJs support about tern

[Raynos]

Generally AMD loaders can trivially transform commonJS & global export files into AMD files so that module authors do not need to add 20 lines of boilerplate to their file.

A problem trivially solved by tooling is best left to tooling.

[tbranyen]

@Raynos I don't think it's as easy as you make it out to be. It's hard (impossible? without best guess) for these loaders to know that the file is actually in need of transformation.

[Raynos]

Agreed, that's why a user will configure, with meta data, that a dependency X it is loading, needs to be transformed from commonJS to AMD

[MiguelCastillo]

Raynos, I am really open to other ways of addressing the issues I have ran into... Could you please elaborate on what you propose I do?

[paulyoung]

@MiguelCastillo RequireJs has a shim config option. That might help in your situation.

shim: Configure the dependencies and exports for older, traditional "browser globals" scripts that do not use define() to declare the dependencies and set a module value.

[MiguelCastillo]

Hi Paul. Firstly thank you for pointing out shims. I make use of them along with the changes I have made to term and acorn.

But I'm guessing that there isn't a clear understanding of the primary problem. Shims is a natural approach to define these dependencies, but that's not really the problem I'm addressing. The actual issue is circular dependencies. I encourage any suggestions, but I encourage even more trying to get tern working requirejs and then we come up with a better solution. If you take a look at my project brackets-tern, you will see exactly how I'm configuring requirejs to load tern. That could also be a spot for feedback :)

Regards,
Miguel

[marijnh]

My first reaction is the same as Raynos' -- that's a lot of boilerplate.

How are circular dependencies a problem? Tern/Acorn don't have any, but that's probably besides the point. The transformation done by the AMD loader shouldn't have any trouble with circular deps.

[mishoo]

Can't resist trolling about why RequireJS is bad: http://lisperator.net/blog/thoughts-on-commonjs-requirejs/ (and though I mention the boilerplate last, I actually think it's the biggest issue.)

[MiguelCastillo]

Well, I can't defend why boilerplate code is good or bad. I just like consistency. Can't explain why some people would prefer to not use requirejs because they introduce more issues than they solve. The article explains how asynchronous is evil... That's when I stop reading.

Circular dependencies are an issue and they do exist in tern. If you look at infer.js you will see a dependency for env.js. Then env.js also calls for infer.js and that's a circular dependency. The same happens with jsdoc.

The boilerplate code is addressing an issue with exports behavior being different in nodes require and requirejs. And mixing in support for non modular loading of tern and acorn, the issue gets worse. This boilerplate code is rather common practice to address these problems. Not sure whats so bad about boilerplate code that's been very well tested. I'm happy without boilerplate code if we have a better solution...

Good or bad, a dependency system is being used tern and acorn. Good or bad, boilerplate isn't bad practice. The issue still remains.

[tbranyen]

@MiguelCastillo you're using the UMD pattern to define, and yet you have comments saying it's code from Knockoutjs. Why? Check out: https://github.com/umdjs/umd

My preferred implementation of AMD is something like what Lo-Dash uses:

https://github.com/bestiejs/lodash/blob/master/lodash.js#L5348

@mishoo That article is absolutely garbage. It's pretty much a troll on trolling AMD.

Edit: @mishoo I'm being a bit harsh on your post, I'll work up a rebuttal post.

[MiguelCastillo]

@tbranyen Yeah, no real reason besides the fact that I had knockoutjs open and that's where I copied/pasted the code from. I like loaddash as well, but I am just more used to UMD.

You basically said what I thought about the article; I just tried to sugar coat it. If anyone reads the article, you most definitely need to read what James Burke had to say. Furthermore, I am not even sure that article has any relevance here...

[Raynos]

@MiguelCastillo browserify's commonJS compiler can handle circular dependencies trivially without forcing UMD boilerplate on module authors.

But sure in the meanwhile until requirejs is patched to handle circular deps either your or @marijnh can maintain an AMD compatible codebase for tern

[MiguelCastillo]

@Raynos thank you for suggesting browserify. I have not tried that so I will for sure try it out later today. I tried requirejs transformation tool without success. What requirejs transformation tool does is that it wraps the definition call with something that's commonjs friendly. One thing that tern supports is loading via script tags. If you take away all the layering of wrapping I did to keep support for script tag loading, then the code can be reduced to a single define call without all the boilerplate code. E.g. You would only need the following

define(function(require, exports, modules){
});

So, the circular dependencies is one issue. The other issue is to keep what tern supports plus requirejs. So a short summary:

1. Circular dependencies resolution. [new]
2. Script tags loading [already in tern]
3. CommonJS loading [already in tern]
4. RequireJS loading [new]

I am happy to maintain an AMD friendly version of tern and acorn. Not sure if requirejs will add support for circular dependencies as they have already suggested ways of addressing this restriction in AMD.

[Raynos]

If circular dependencies can be trivially refactored away that's definitely a bonus

[ivan4th]

Note that besides the boilerplate problem, the commit introducing requirejs support reverts some changes from recent tern commits (depth > 6 instead depth > 3 at least)

[marijnh]

See commits marijnh/tern:76be1f8eee184c104d4d328ca93c4002e42b6d72 and 711faaa . I have not tested with an AMD loader yet, so I might have made a mistake in the lines that handle that environment, but theoretically it should be okay now -- node and script tags still work.

I've simply killed the non-essential parts of the screenful of boilerplate, and also used the prelude to include dependencies, which actually results in a header that's still ugly, but small and useful enough to not be too offensive.

[MiguelCastillo]

Marijn, thank you for your changes... Great first step.

But, circular dependency is still a problem.

Either way, really... Thanks for adding this! It is a great start.

[marijnh]

Why would you change boilerplate code I added following AMD best practices for boilerplate code that "I have not tested with an AMD loader yet"?

I believe I described my reasons in this very thread.

Doesn't requireJS handle circular deps at all? That's odd. The circular deps are not going away.

[marijnh]

Try with cbcf6f5

[MiguelCastillo]

Yeap, that did the trick. Thank you! You could easily take the code below to create unittests for requirejs... I would volunteer to add one if you want. :)

var ternRequire = window.requirejs.config({
    "baseUrl": require.toUrl("./tern"),
    "map":{
        "*": {
            "acorn/acorn": "node_modules/acorn/acorn",
            "acorn/acorn_loose": "node_modules/acorn/acorn_loose",
            "acorn/util/walk": "node_modules/acorn/util/walk"
        }
    },
    waitSeconds: 5
});


// Setup the dependencies for acorn...
ternRequire(["tern"], function(tern) {
    console.log(tern);
});

[marijnh]

I'm not currently running any browser-based tests as part of the automatic test suite, but I did create a page similar to that (simpler, actually, requirejs.config({baseUrl: "..", paths: {acorn: "node_modules/acorn"}}); sufficed) to verify that my changes helped.

[MiguelCastillo]

Yeah, that's perfect! I am sure that the brackets team will appreciate this change