node r.js -o build.js with no appDir duplicates baseUrl directory about r.js HOT 8 CLOSED

This is done in case there will be dynamic loading from the baseUrl. If you just want one output file, see Optimizing one JavaScript file. If that is not what you are looking for, please feel free to reopen this issue with more info.

from r.js.

Hey, thanks for getting back to me so quickly! Optimizing one JS file is nice for doing exactly that.., however I'm more interested in exporting out a library I've written. Naturally it's only defined and instantiated when need be in projects, but I'd like to open it up to anyone — regardless of if they have or know require or not.

What I have:

• A define module of the base class that handles everything.
• A number of define modules that the base class includes.
• A couple of third party files with paths rewritten for them. (underscore.js and text plugin so that I only have to write underscore or text! in the define modules and worry about their relative path in the main require file)

So what I've done so far is create a new main.js that only requires the base class. I've run the command line optimization for this file. Slight tangent: Is it possible to write a build.js configuration file for this? The main reason I ask is because my command line was like 3 lines tall at 1920 x 1080 resolution as a result of my build environment being on the other side of my computer directories than the base class I'm exporting.

Finally, despite the fact that all the files have been concatenated into one I still needed to use require.ready in my html document that I was trying to test on. I saw almond and tried using that instead of require, but was still unable to get to run in the test because the way I've setup underscore was by requiring it, but not mapping it to an argument in a module (filling the global namespace).

My main file looks like this:

require({
  "paths": {
    "underscore": "/third-party/underscorejs/underscore-min",
    "text": "requirejs/text"
  }
});

require(['name/of/base/class'], function(base) {
  var root = this;
  var namespace = root['namespace'] = namespace || {};
  root['namespace']['class'] = base;
});

I apologize for telling the longer story... What I'm really interested in is understanding how to take define modules and exporting them for public consumption in a way that doesn't necessitate require.

from r.js.

Yes, you can use a build.js for the commands, just change them to object name/properties. So name=value becomes name: 'value' (if value is a string) in the build.js file.

For your main use case, that was one of the goals with almond. However to use almond, you will need to use this r.js snapshot -- it has some changes that have not made it out in a release yet (but they will be part of the upcoming 0.27.0 release).

I did not quite follow the issue with underscore and such. Maybe if you can show me more of the project layout that may help. And just to confirm, underscore-min.js is an unmodified version of underscore? Or, if you were not using the aforementioned r.js snapshot, using that first.

One thing to note: the build profile requires the paths settings in the build profile. It will not read the config in your main.js file -- this is done because it is common that the build layout is different from the runtime layout.

from r.js.

Cool — I'll give these a try and keep you posted. Just to confirm I would use r.js snapshot instead of r.js for almond use? Like node path/to/rjs/snapshot/r.js -o build.js?

The comment about underscore was just that I'm renaming it and as a result leaves for some additional path params in the options when optimizing. It's unaltered pull of underscore. Just to be clear I'm using it like:

require({
  "paths": {
    "underscore": "/third-party/underscorejs/underscore-min",
    "text": "requirejs/text"
  }
});

require([
  'path/to/some/module',
  'underscore'
], function(module) {

  require.ready(function() {

    console.log('underscore exists', _);

  });

});

Finally, I did notice and is duly noted that r.js neglects the config in main.js. I like that decision. Thanks so much for the help!

from r.js.

On Fri, Sep 23, 2011 at 8:40 AM, Jono Brandel
[email protected]
wrote:

Cool — I'll give these a try and keep you posted. Just to confirm I would use r.js snapshot instead of r.js for almond use? Like node path/to/rjs/snapshot/r.js -o build.js?

Yes, exactly.

The comment about underscore was just that I'm renaming it and as a result leaves for some additional path params in the options when optimizing. It's unaltered pull of underscore. Just to be clear I'm using it like:

Finally, I did notice that r.js neglects the config in main.js. I like that decision.

   require({
     "paths": {
       "underscore": "/third-party/underscorejs/underscore-min",
       "text": "requirejs/text"
     }
   });

   require([
     'path/to/some/module',
     'underscore'
   ], function(module) {

     require.ready(function() {

       console.log('underscore exists', _);

     });

   });

OK, looks pretty standard.

from r.js.

Thanks so much for the help! I was able to get it up and running! I had to make an interesting modification to main.js in order for my usage of the BaseClass to work like how I wanted. Here's the usage I want:

<!doctype html>
<html>
  <head>
    <script src="path/to/BaseClass.js"></script>
    <script>
      window.onload = function() {
        var b = new BaseClass();
      };
    </script>
  </head>
  <body></body>
</html>

and here's the modified main.js that builds to my library:

require(['path/to/BaseClass'], function(BaseClass) {
  var root = this;
  var namespace = root['namespace'] = namespace || {};
  root['namespace']['BaseClass'] = BaseClass;
}, undefined, true);

upon further inspection in almond. The fourth parameter in require is forceSync simulates async callback. But as the restrictions section promotes... do you need to simulate async callback?

from r.js.

What you could do instead is to just use define() instead of require() in main.js (I'm assuming that is the only non-configuration require() call in main.js). That way the code would be a bit more portable and not depend on a non-standard require() signature that AMD uses for expediency/small download size.

In general though, the issue is because there is an assumption that with page load means all scripts/modules are defined. That is not necessarily the case with AMD modules, in fact normally it is not. But if your primary use case is to just use AMD modules for internal development but just surface a built script to users where everything is defined up front, then what you did makes sense. And in that scenario I would just use define() in the main.js file.

from r.js.

Cool, thanks so much for the help! I'll give this a go.

from r.js.