Hi I have just started reading requireJS and come to point about shim configuration I understand that part too but confused in one requirejs Api statement says "The global Backbone will still exist on the page too."
"Then, later in a separate file, call it 'MyModel.js', a module is
defined, specifying 'backbone' as a dependency. RequireJS will use
the shim config to properly load 'backbone' and give a local
reference to this module. The global Backbone will still exist on
the page too."
whats this means the global Backbone will still exist on the page too.
can anyone explain.
Thanks
Vivek
It means backbone will be define at the global(window.backbone) level AND as a module
Related
I was searching where nodejs global object comes from, and found that global object actually comes from a module called... NodeJS. What exactly is this module? Perhaps the objects in this module are auto-imported to the global context? Is there any document about this?
The problem is that, because of its name NodeJS, it is so hard to google it to find where this is documented.
There is no NodeJS module in node, I think that you are refering to typescript namescpase from typings https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/node/globals.d.ts#L144
declare var global: NodeJS.Global;
global object is set on Global context during Node.js environment initialization, starting probably from this point https://github.com/nodejs/node/blob/master/src/api/environment.cc#L446
During node.js debugging we can see that during running script loaders.js https://github.com/nodejs/node/blob/master/lib/internal/bootstrap/loaders.js
there is no global object on Global scope
But during running thru node.js script https://github.com/nodejs/node/blob/master/lib/internal/bootstrap/node.js the global object is in place
I am trying to lazy load module rather than adding components in entry component because i.e adding overhead to the chunk size. (Also, I don't need routing)
Here is what you need to know about dynamic components in Angular
I have followed the steps mentioned by max in his article.
I came across below error
ERROR in ./node_modules/systemjs/dist/system.src.js
Module not found: Error: Can't resolve 'fs'
After some research, I found that now it's the responsibility of node to provide the 'fs' module And for this, I need to add
"target": "node"
in webpack.config.json. However, Angular 6 has disabled ejecting Webpack.config file anymore.
So, is the lazy loading of module still possible without routing?
I have a Node.js project written in TypeScript. In my project, I have a folder named "public" which contains the client side code & HTML and also a file named classes.ts which is supposed to be shared to the server side.
The problem is that I need to add "export" before the classes declaration in order to make them accessible in the server, but then in the browser I get this Error:
Uncaught ReferenceError: exports is not defined
I found these questions:
https://github.com/Microsoft/TypeScript/issues/5094,
Setup a Typescript project with classes shared between client and server apps?,
Share module between client and server with TypeScript,
which suggests using commonjs in the server but amd in the client. The problem with this solution is that they have 3 different projects (server, client and shared) whereas I only have one project in which I use commonjs.
Another suggestion is:
the other option, which is more convoluted and will require a post
build step to massage the code; if you can not use module loaders in
your client code, is to isolate all module dependencies in your server
code, then in the shared, they are just classes. Build the shared
files without --module, and no exports or imports, but all inside a
single namespace, say namespace MyApp { ... }; in your client code,
you include them directly, and emit using --out. in your server code,
you first emit the shared code to a single file, shared.js, and a
single .d.ts shared.d.ts, augment these with some code to export them
as a module, e.g. append exports = MyApp at the end of your shared.js
and shared.d.ts, then import them from your server code.
But I don't want to deal with updating .d.ts files all the time, and I'm also not sure it will work in one project.
Any suggestion how to make a TypeScript class accessible both in browser and server?
Any help will be profoundly appreciated!
This is absolutely possible.
I have a project containing both SPA client application that runs in browser and server running in node.js that both share common typescript classes. For all of this I have just one tsconfig.json file (I am still not sure that this is the best approach but for now it works just fine)
Here are parts of my setup:
Use modules (previously called external modules). No need for namespaces and d.ts files for your own modules.
module = "commonjs" in tsconfig.
On client side use System.js as module loader (this will solve your 'Uncaught ReferenceError: exports is not defined'). You can use angular2 5 min quickstart as reference how to setup system.js.
It works like a charm.
I am working on a project which works fine on browser , now we are trying to run it on server side using nodejs.
I have below configurations :
node : v4.2.1
npm : v2.14.7
and when I am trying to run my project on nodejs , getting the error as :
Shim config not supported in Node, may or may not work
Since the modules and dependencies (AMD) are working fine on browser I assume the shims config are correct .
Please let me know if I am missing something ?
https://github.com/jrburke/requirejs/issues/1443
Regards
Manish
Since the modules and dependencies (AMD) are working fine on browser I assume the shims config are correct .
That's an incorrect assumption. The problem is that Node.js operates with a set of basic assumptions that are very different from how browsers work. Consider this statement:
var foo = "something";
If you execute this at the top of your scope in Node.js, you've created a variable which is local to the file Node is executing. If you really want to make it global, then you have to explicitly shove it into global.
Now, put the same statement at the top of the scope of a script you load in a browser with the script element. The same statement creates a global variable. (The variable is global whether or not var is present.)
RequireJS' shim configuration is used for scripts that expect the second behavior. They expect a) that anything they declare at the top of their scope is leaked to the global space and b) that anything that has been leaked to the global space by scripts they depend on is available in the global space. Both expectations are almost always false in Node. (It would not be impossible for a module designed for node to manipulate global but that's very rare.)
The author of RequireJS explained in this issue report that he does not see it advisable for RequireJS to try to replicate the browser behavior in Node. I agree with him. If you want to run front-end code in the back-end you should replace those modules that need shim in the browser with modules that are designed to run in Node.
I've been trying to modularize my server and web apps. i've read about exports and module.exports in Node here and here.
http://www.sitepoint.com/understanding-module-exports-exports-node-js/
http://liangzan.net/blog/blog/2012/06/04/how-to-use-exports-in-nodejs/
I get how it makes the functions available to other files / scripts, but what happens to the modules required within the exported file? If I require websockets in some file, export it and require it within another file, does the other file inherit the websockets from the exported file? Is it similar to a header file in C and just pastes that module into your file?
When you require() a module in node, it gets executed inside a closure and the value exported by the module is cached. So any additional require()s for the same module (located at the same absolute path) will always get the same object/value/whatever.
So in your websockets example, the require('websockets') that you do in your module is not automagically available to anyone requiring your module. Everything in a module is done within a separate, local scope (you can read/write the global scope accessible by all modules, but you really should not do that). This is why you need to explicitly export values for them to be seen by outsiders.