

Reusing require.js modules in Node.js with AMDrequire - marquex
http://arqex.com/874/reusing-require-js-modules-node-js
AMDrequire is a npm package that makes Node.js able to load require.js modules like if they were native Node ones, as well as continue to load its own modules as usual, allowing to reuse browser code in the server.
======
wildpeaks
Interesting, it might solve my dilemna regarding RequireJS vs Browserify given
the npm requirejs has one troublesome issue with the paths aliases config
getting erased (& can't be restored either) once .optimize has been called to
make an Almond build. That's why I switched to Browserify in most recent
projects, however I have one issue with it and it feels I'm missing something
obvious:

What is the right way to use Browserify transforms server-side?

\------------------

Because Browerify assumes you use Node's own _require()_ server-side while
RequireJS (and now also AMDRequire) have their own module to provide an
enhanced require function. The closest I could come up with (besides giving up
and precompiling to a single file before calling Node) is using the deprecated
_" require.extensions"_ to preprocess the file, similar to requirejs loaders,
e.g. for handlebars you could add in your Node start:

    
    
      var fs = require('fs');
      var Handlebars = require('handlebars');
      require.extensions['.handlebars'] = function (module, filename){
        var code = fs.readFileSync(filename, 'utf8');
        module.exports = Handlebars.compile(code);
      };
    
    

Then _require( './something.handlebars')_ in modules you share client and
server-side gives you the already-compiled template regardless if you're
running in Node or in the browser (if you also use the handlebar transforms
for Browserify).

I'm sure I'm missing something very obvious here.

------
couchand
I disagree with the assertion that the browserify transformation implies it's
"not the same code". If you're (following best practice and) concatenating and
minifying your assets, is that not the same thing?

The compilation step that browserify uses is little more than concatenate + a
little bit of sugar. Practically speaking why does this matter?

I'd much prefer to deliver less code to the client if possible, so I don't see
the rationale for adding a dependency on a dependency manager.

~~~
greggman
I don't know browserify well but I'd assume having a compile step is the part
that sucks. If you can use require.js style until shipping time you can debug
the actual code directly instead of the compiled code. You see each module in
the debugger as its original file.

~~~
alistairjcbrown
+1 - this is why I love requirejs - lazy load modules in development, compile
for QA and deployment.

Update: My other love for requirejs is that you don't need to use relative
paths when requiring a module. Once you have a relative path, you can't change
the location of either dependant or dependency. The require config lets you
separate what you call the module from the location of the file.

~~~
danabramov
I tried porting a project from Require to Browserify and I gave up because of
relative paths issue.

------
alistairjcbrown
How does this differ from the requirejs module for Node?

[https://www.npmjs.org/package/requirejs](https://www.npmjs.org/package/requirejs)

~~~
spencera
Looks like it offers a subset of the features by allowing you to use the same
require() function for both amd and commonjs modules.

[https://gist.github.com/spenceralger/946ddc6c55d997d4a028](https://gist.github.com/spenceralger/946ddc6c55d997d4a028)

~~~
alistairjcbrown
Ah, thank you - I misunderstood the crucial piece "load AMD modules like ...
they were native Node modules".

I guess I can see the value in this, if you're retrofitting a new module in
the AMD style to an existing node application which does not use that style.

