I've got a site that doesn't use RequireJS. I load all of my code in <script> nodes index.html.
I found a module on NPM, azure-storage, that I'd like to use. However the js files in the module contain code that assumes that I'm using RequireJS; The documentation says to use it via a require(), and the javascript files itself is littered with more require() calls.
I do not mind taking a dependency on RequireJS to consume this package. However all of the tutorials that I found gave me the impression that I need to restructure my entire application in a RequireJS style before I could require() the dependency that I found on npm.
Please tell me that I'm wrong. Is there a simple way for a non-RequireJS site to consume a RequireJS module?
In case it matters, my web app is built on AngularJS.
The problem here is browsers don't support require or any notion of modularity, really.
Assuming you just want to assign whatever azure-storage exports to a name in the global namespace (which assumes azure-storage and its dependencies will only consume APIs available on the browser), there are tutorials for using browserify or webpack to that end.
Either of those will build the azure-storage package and its dependencies into a solid .js file you can use in a <script> node that will assign whatever the module exports to a global name of your choosing.
Related
While requirejs is capable of using npm-installed modules, how do I use requirejs in first place if itself is installed via npm install requirejs?
I have read examples of using requirejs listed in the example-section. They all seems to assume require.js is downloaded into a specific location. Since the documentation specifically said
do not do something like require("./node_modules/foo/foo").
I guess it is not right to put in index.html something like:
<html>
<head>
<script data-main="scripts" src="node_modules/requirejs/require.js"></script>
</head>
<body>
<h1>Hello World</h1>
</body>
</html>
What is the recommended way to use requirejs if it is npm-installed? If I missed something from the documentation please let me know. Thank you
It looks like you are conflating a bunch of different uses of RequireJS:
How can you use a RequireJS installed through Node in the browser?
You can just install it with npm install requirejs, and then you have your HTML file have a script element that points to node_modules/requirejs/require.js. Exactly as you show in your code snippet. That's all there is to it. This being said, I don't like to have node_modules in what I deploy, so I typically have my build process copy require.js elsewhere.
How can you load npm-installed modules with RequireJS in Node?
Suppose without RequireJS you would load the module foo by doing require('foo'). You install RequireJS and load it as requirejs. How do you load foo using RequireJS? You can just do requirejs('foo'). So long as RequireJS does not find it through its own configuration, it will issue as a last resort a call to Node's own require, and will load it this way? Here's an illustration. Install RequireJS with npm install requirejs. Create this file:
var requirejs = require("requirejs");
var fs = requirejs("fs");
console.log(fs);
Then run it. You'll get on the console Node's fs module.
How can you load npm-installed modules with RequireJS in a browser?
It depends on the modules. RequireJS does not contain code that will magically make a npm-installed module work in the browser. It ultimately depends on how the modules are structured. Some cases:
A. Some npm-installed modules can be loaded with RequireJS without modification. There's one library I've authored which is distributed through npm and yet is a collection of AMD modules. It is trivial to load them with RequireJS in the browser.
B. It may require being wrapped in define calls. I've recently loaded merge-options in one of my projects with gulp-wrap-amd. merge-options is a CommonJS module. It does not support RequireJS out-of-the-box but if you wrap it with a define call, it will work.
C. It may require something more complex before it will be loaded in a browser. For instance, if a module relies on Node's fs module, you'll have to provide a replacement for fs that runs in a browser. It will presumably present a fake filesystem to your code.
I'm new to Node.js web development. Just created a project using ExpressGenerator (project structure generator for ExpressJS framework).
The question is: if I want to use FineUploader front-end JS library for my application, which is provided through NPM package, how should I embed it into my project properly? package.json manages server-side dependencies. When authors of front-end module publish it as npm, what approach to further usage they imply? Another package manager like Bower?
You are correct that package.json manages server-side dependencies but not entirely. You can - and should - rely on it to manage front-end dependencies as well.
For that to work you will need a module bundler, to package the node module for the browser. Some of the most popular bundlers for accomplishing this include Webpack, browserify, rollup among others.
Also note that you can delegate the bundling of node js modules to cdn services such as unpkg or wzrd so that all you need to do to use a node module in your front end code is include a link in your html to the cdn bundled module
I'm learning how to use Flux and I encountered the following line in the documentation: "We can use Node's EventEmitter to get started with a store."
I understand that you can use things like Browserify to do the bundling and minifying, grabbing all the dependencies that Node code has to make the bundled browser-compatible JS file. But what's bugging me right now is how you know what you can do this with. How do we know what Node code we're allowed to use in the browser?
So, first of all let's consider that when in node you have
JavaScript modules that are the 3rdParty modules written in JavaScript (ECMA5, ECMA6 and even TypeScript or CoffeScript) etc;
Node built-in module. Those are node Core modules like fs, path, util, etc.
native compiled module called Addons that are are
dynamically-linked shared objects, written in C or C++;
Then you have the packager / module bundlers
Browserify
Webpack
the transpilers i.e. source to source compilers that typicall will handle syntax tranforms like
Babel.js that shims modern JavaScript to legacy engines
and the techniques
ECMA5 Shim to support legacy JavaScript engines
HTML5 Cross-Browser Polyfills
Because you need to do polyfills if you want to transform not only syntax but even globals (like the Promise), so you combine transpiler to polyfill having like babel-polyfill
Finally we have different kind of modules design patterns (modules format) to be handled for the bundling process:
AMD modules format
CommonJS modules format
and formats that are not in those ones that must be bundled/shimmed - where possible - through custom loaders.
That said, native modules will not run in the browser: you cannot bundle a native module through Webpack. Ordinary modules will, but not all. This is due to several reasons. There are some specific methods that cannot be "browserified" or "webpacked". Let's take as example fs. Can you put this built-in module in the browser? There are some abstraction for that called brfs, that are transforms for built-in node apis fs.readFileSync() and fs.readFile(), so you will do
$ browserify -t brfs example/main.js > bundle.js
to get
var fs = require('fs');
var html = fs.readFileSync(__dirname + '/robot.html', 'utf8');
console.log(html);
This will not work for every non built-in modules, in the npm modules jungle, so WebPack has a module.noParse option to exclude Addons modules, non supported modules, etc. - see here about that.
So you have to look at the list of the transforms that means you can apply this transform to browserify to obtain like the fs transform mentioned above.
So that said, how do you know that a certain module will run in the browser? When you design your web application and Node backend you have to do opportunistic design choises to design shared modules/library that will run in both the environment, so being shimmed/packed at some point, like object models, application logic, etc., other modules that will deal with the File System I/O or will use native addons, so that will work in the server only, packing through wrappers it's possibile, but the behavior will look differently, as we have seen in the fs example above, and web specific modules, so it's a design matter.
A note can be added about networking modules i.e. node http, https that thanks to library abstractions like node request will run everywhere or using specific transforms like http-browserify.
I setup a website with regular client side RequireJS today. Than I did some research on node, got that installed and setup my first module in node. When I setup the first require, I loaded the Require.JS file and I get all that. The thing that is confusing me is, I created a file called test.js and within that I am including:
var require = require("requirejs");
which is actually including the node require, not the original require library I was using right?
So like are they completely different? Can they used together?
Doesn't Node already have a module loader?
Yes Node does.
That loader uses the CommonJS module format. The
CommonJS module format is non-optimal for the browser, and I do not
agree with some of the trade-offs made in the CommonJS module format.
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. If you want to use
define() for your modules but still run them in Node without needing
to run RequireJS on the server, see the section below about using
amdefine.
Source: http://requirejs.org/docs/node.html#1
Ok, so modules written for node.js can be combined into bundles with browserify.
But just in case I only have a bunch of bundles created by browserify and not the source, would it still be possible to 'require' or otherwise use these bundles and their contents in a node.js environment besides the browser? (granted that the code does not do anything browser specific)
Ok, so modules written for node.js can be combined into bundles with
browserify.
Firstly I am not sure what you mean by this, as browserify was created to do the opposite. Browserify was made to allow the use of node's require() statements in the browser.
But just in case I only have a bunch of bundles created by browserify
and not the source, would it still be possible to 'require' or
otherwise use these bundles and their contents in a node.js
environment besides the browser? (granted that the code does not do
anything browser specific)
Yes in short, as long as the modules do not use the global window scope because window is undefined in node.js. Common helper packages like lodash, axios, moment, bluebird, and q promises all work in node.js.
Generally though, packages are often modified to work in both the browser and node.js. There is a browser attribute option in package.json files that allows you to specifically target the browser when publishing npm modules. Often files designed for the browser are minified down to one file because of how files could potentially be imported into the browser. This is not necessary with node and there may be many files in a node project.