I'm currently working on a server side Node project. Although node has it's own module loader using CommonJS I'm evaluating whether to use RequireJS with it. Whilst there are advantages to using RequireJS with Node if the application that has some client side aspects to it, I can't find any benefits for a project which is entirely server side.
Is it commonly thought that for a 100% server side Node project, there are no real advantages to incorporating RequireJS?
There exist reasons to use RequireJS server-side but they are few. Unless you can state a reason, like:
I must use RequireJS because X
where "X" is a reason which justifies the use of RequireJS, then you should not do it.
Note that just wanting to write modules in the AMD format is not reason enough as there exist loaders (like node-amdl-loader) which allow loading AMD modules in Node. I actually use this when I want to test code which does not depend on a browser. I write the modules in AMD format and specify that if used in Node, an AMD loader like node-amd-loader should be used. This way the library works both in Node and in the browser but I test it in Node.
One reason to use RequireJS server-side is for instance, if you need to run code that needs a DOM implementation. If you use something like jsdom to provide the DOM and the code you want to load is a series of AMD modules, then using RequireJS to load the code into the DOM environment created by jsdom makes sense.
I've never found a good reason to use RequireJS in node. However, RequireJS can be run on node, and the documentation has a brief explanation of why you might want to run RequireJS on a Node server:
By using RequireJS on the server, you can use one format for all your
modules, whether they are running server side or in the browser. That
way you can preserve the speed benefits and easy debugging you get
with RequireJS in the browser, and not have to worry about extra
translation costs for moving between two formats.
Most of that is only useful in a project that also has a client element. If it were me, I'd stick with Node's internal module loader.
Related
I am used to simply using process.cwd() directly inside of node applications, however, I have recently read the node docs and saw that it recommends importing it from node:process.
So what is the difference from just calling it directly?
process.cwd()
vs importing it and calling it:
import {cwd} from 'node:process'
cwd()
I am currently building a CLI application in case that makes a difference.
Is there a difference?
Which one should I be using?
importing it from node:process guarentees that you get the built-in process module, not some global that some other code in the project has configured or overridden.
This may be done for safety reasons or just for robustness reasons so other modules in the project can't hack on a global process object before you get to use it.
It also may not normally be needed, but is considered good project hygiene as it deters certain types of hacking.
I have written a self contained angular js module using browserify in order to make use of the commonJS/Node style syntax.
The module works fantastic when tested by itself, so I then use gulp to minify and host that on GitHub.
I've then imported that into another app that is also using browserify. When I run browserify it seems to try and rebrowserify the module and causes no end of problems.
I believe this is because the module requires angular and jquery and qtip2. So it's obviously trying to re parse these.
Is there a standard to not parse modules, or is there a way to exclude the browserifying of the modules? Or is it best to not include things like angular and jquery within your modules? I was trying to make them perfectly stand alone, maybe that's unwise?
Many thanks!
I would suggest providing both options, if it is important for you to have a standalone version that includes angular. This will provide people using your code with a total of three ways of using your code: Using the standalone version, the version that only includes the module, and cloning the repository directly and including the source files as part their build process.
I generally use the third option, but people who don't have build processes will likely prefer the first or second.
I just wrote a module ( https://github.com/mercmobily/simpleDeclare ) and made it available as a Node module via NPM. It follows CommonJS.
I would like to make it also available to people using Bower, and AMD-like loader, and a straight include using the browser.
What's the current pattern to make this happen? Or, is it even possible? I remember seeing a few modules that did it, but cannot find them and am only finding outdated and not-so-definite information (but I suspect I am looking for the wrong thing).
Is there a way to test automatically if a JavaScript module is compatible with CommonJS (Node) or AMD module formats? Furthermore, how could one write it as a Grunt task?
Compability is an important feature of a module and should be able to be tested automatically at least in some degree. For example a change in a building configuration could produce a compability error that cannot be noticed by unit tests that use only browser interface of the module, like is the case with QUnit. There might be also possibility that the compability-enabling code of a module (e.g. self-made UMD wrapper) is so messy that it is hard to say if a change elsewhere in the code could have an effect on the compability part of the code.
One could use tools that generate probably correct wrappers of different module formats. For example grunt-umd and uRequire are such tools. But as they too depend on the build configuration, how you can be sure that the compability really is there without any testing?
I don't think there is an out-of-the-box or obvious solution.
In general there are several approaches you could take to solve your problem:
Write your code in one module format and use transpilers to produce the other module formats. Babel (5) is pretty good at doing this, but there are probably others.
Use a parser like esprima and statically analyze the code. The "standard" wrappers like those on https://github.com/umdjs/umd are probably easy to detect patterns. Custom wrappers might be harder and you might need a few revisions before you get it all right.
Trial-and-error: Have your grunt task create files (e.g. generated from .jade templates) that include the supposed module in each of the manners you care about (AMD, browser globals), then "run" those (e.g. using nightwatch or selenium) and see if any errors occur. (This might be very difficult to get right if the module you are trying to load has dependencies)
So I've been building a single page web app for a while now and I've been writing all my code in an extremely modular approach. I've been using the javascript module pattern for all modules and my main API uses the revealing module pattern to expose a small API for plugins and other modules.
So even if I've been writing my code like this someone mentioned I should be using require.js as it gives a better modular approach.
I decided that require.js doesn't really make it more modular so my next thought was how require.js separates out dependencies. Require.js forces you to name dependencies in each module file. But this to me seems to be a task I have to do for every module and I have a lot of modules. At the moment all my files are concatenated into a single javascript file in my grunt build process so really all my files are loaded at the start. I need most of my modules loaded at the start so it made sense to do this.
So my question is... Should I use require.js even though my code is modular and all my files are concatenated together and loaded at the start? Do i need to worry about dependencies or loading order? Any help/advise or previous experience when dealing with this situation would really help. Thanks
Have you had annoyances putting <script> tags in the correct order to handle dependencies right?
Having a requirejs config file where you declare the third-party code and your own code dependency tree is a much more organised approach than declaring <script> tags by yourself.
When you are testing your app in dev environment, wouldn't be helpful to have all those modules in separated files that are easier to debug instead of all of them concatenated?
With requirejs you can switch between optimised/concatenated/minified code used in production environment and a list of independent files representing each module in the development environment.
Are you creating a global variable for each module in your app?
Requirejs avoids creating a global variable for each module so your global scope doesn't get cluttered.
It's usually a good practice to follow conventions in the way you declare modules. Requirejs implements AMD specification that is a well thought way of loading modules in client javascript.
http://requirejs.org/docs/whyamd.html
It's way easier to follow conventions if they're already implemented in a mature framework. And sometimes we don't notice but between apps we do the same thing differently and that affects in the maintenance phase.
Take a look at the requirejs optimizer. Look all the options it give you. It allows you to exclude files, to change versions of a given module, to change the minification tool, to integrate the optimization process with other tools like grunt or bower, etc.
http://requirejs.org/docs/optimization.html
If you don't need any of this, then just continue doing it in your way.