RequireJS - define function is not returning dependencies correctly

Question

I'm using RequireJS and when I define a new module using the function "define" I see the dependencies were resolved but the objects are not the modules I defined.

All the modules are defined in AMD format, setting a name, array of dependencies and a function. The exportation is done by return an object.

The dependencies resolved by "define" have these properties: exports, id, packaged, and uri. If I then call require function the dependencies are set correctly.

UPDATE: I created a test example with the described issue

HTML:

<!DOCTYPE html>

<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>Test</title>
    <script src="/Scripts/require.js" data-main="../Scripts/main"></script>
    <script src="/Scripts/module.js"></script>
</head>
<body>
    <div> 
    </div>
</body>
</html>

main.js:

require(["module"], function (module) {
    module.test();
});

module.js:

define([], function () {

    function test() {
        return "a";
    }

    return {
        test: test
    };
});

Console: Uncaught TypeError: module.test is not a function

This happens because module is not resolved to the real module but to an object with properties:

-config { arguments: null, caller: null, length: 0, name: "config" }

-exports { id: "@r5", uri: "../Scripts/@r5.js" }

Setting a module name in the define function has the same result.

NOTE: in the example there was an issue detected by @Louis. A module cannot be named "module". This helped me fixed the example but didn't fix my real issue. Below I describe the solution.

SOLUTION:

My issue was related to a library called Ace (HTML editor). This is the link that helped me solve it: https://github.com/josdejong/jsoneditor/issues/173

What does your require config look like? How come you use bConfig at one place and builderConfiguration at another? Are they the same? — dbf
– dbf, Commented Dec 4, 2017 at 23:20
That was a typo in the question, I have already fixed it. I don't have a require config, is that mandatory? require functions resolves dependencies correctly so define should do it the same way. I'm using bundles to load the files. — Francisco Goldenstein
– Francisco Goldenstein, Commented Dec 5, 2017 at 12:33
No define should not, just because require does. You have to understand how require.js locates modules by settings it's path, either absolute or relative. If you do not receive a failure that bConfig module could not be loaded, or normalized to a module according to your require.config settings, then the only problem I can think of is that you have multiple bConfig.js files in your project directory. Doesn't make sense otherwise. — dbf
– dbf, Commented Dec 5, 2017 at 17:17
I don't have multiple bConfig.js files. No errors, the problem is how the objects are resolved to something else with the properties I specified in the question. — Francisco Goldenstein
– Francisco Goldenstein, Commented Dec 5, 2017 at 17:38
You won't get anything more than guesses until you edit the question with a minimal reproducible example. I've used RequireJS for years, and I've never ever seen the behavior you describe, and there's nothing in the code currently in the question that would explain why you get the behavior you describe. (To answer a question in an earlier comment: you can absolutely run RequireJS without setting a configuration explicitly, if the defaults happen to be what you need.) — Louis
– Louis, Commented Dec 5, 2017 at 19:55

Louis · Accepted Answer · 2017-12-06 14:28:37Z

3

With the edit you made, it is now possible to diagnose the issue. Do not name any module you write with the name module, and the problem will go away.

The name module is one of three reserved module names: module, require and exports. You should never name any of your own modules with these names.

When you ask RequireJS to load module, it is not loading your module. Instead, it simply returns an internal structure which is meant to provide information about the current module. It has fields like id, which gives the current module id (i.e. the module name) and url which gives the URL from which the module was loaded, and so on and so forth.

answered Dec 6, 2017 at 14:28

Louis

152k28 gold badges287 silver badges332 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

Francisco Goldenstein Over a year ago

You are right about module generating a conflict and lead me to find the real issue in my project. I was referring a library called Ace (HTML editor) and there was a conflict with it). Thanks!

dbf · Accepted Answer · 2017-12-06 16:11:35Z

Ok, so after reading

properties: exports, id, packaged, and uri.

I'm guessing, like @Louis said we would, that the example in the OP's question is not the example in the OP's (test-)project.

When defining a module, there are 2 (and lots of more) general ways of doing so.

On of them is explained in the docs titled CommonJS.

If a module is defined with

define(function(require, exports, module) {

   console.log(module);

});

then the 3rd argument module will indeed contain exports, id and uri as in.

{
   config: function config()
   exports: Object {  }
   id: "js/modules/handgrip/index.js?bust=1512509846564"
   uri: "js/modules/handgrip/index.js?bust=1512509846564&bust=1512509846564"
}

In order to "return" your module in the given context, you can export it with

define(function(require, exports, module) {

   // require a depedency already loaded in context
   var someDep = require('someDep1');

   module.exports = {
      // whatever this module is about ..
   }
});

Only if you define the module with a name, followed by dependencies, as in

define('thename', [ 'someDep1', 'seomDep2', 'etc..' ], function(dep1, dep2, ..) {

   // the arguments in this context are those listed in order as defined in the array (parameters)

}

you get your expected results ..

-- update after edit

Was in a Scrum-meeting, sorry ;) So it's quite clear, as @Louis wrote.

module, exports and require are reserved words.

The following have the same results

define(['require', 'exports', 'module'], function(require, exports, module) {
  console.log(module);
});

define(function(require, exports, module) {
  console.log(module);
});

I'm using the last option, define with module name and dependencies. I don't see why this would solve the issue I described. Why am I getting my modules with properties like exports, id, packaged, and uri instead of the real properties? and why when I use require(...) to get them explicitely it works?
@FranciscoGoldenstein Unless your code is top secret, no one is able to help you buddy ;)
It's not top secret :) it's a big project that was all in one file, I separated it into multiple files, defined modules and implemented RequireJS. It's hard to give you real code because it's a huge app. I thought it was gonna be good enough with my question.
@FranciscoGoldenstein It was to be expected that it is a huge project. Though the module given in de dependency array should be known, in your example bConfig, the problem could be anywhere, but just an outtake of the code where it goes wrong, e.g. definitions in which order modules are declared and how they are exported (e.g. factory, etc), would be helpful. Are you the author of this bundle?
I added more information in the question. definition is in AMD format and exportation is done by returning an object. I didn't write most of the JS code, I just inherited it and I'm refactoring so developer don't need a month to understand it.

Collectives™ on Stack Overflow

RequireJS - define function is not returning dependencies correctly

2 Answers 2

1 Comment

9 Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

1 Comment

9 Comments

Related