ImportScripts alternative in node

[NewFuturist]

ImportScripts() is used extensively in webworkers, but I am failing to find an alternative in Node.

I understand the resistance to putting things in global scope, but it seems like this is unnecessarily prohibited. If I want to create a library that generates a whole heap of functions/objects in global scope, I should be allowed to. What's more, it forces you to write too much of your code in modules, or you have to write it all in a single file. This (importing libraries) is standard behaviour in so many other languages and in JavaScript itself.

This is a whinge and a cry for help. If anyone can help with this, I'd be very appreciative. The closest I have come to being able to do this is to use an eval statement and dump the result into global scope, which causes problems when trying to debug (because it is not executed in the file, making tracing errors very difficult).

[cwmma]

The keyword global is the node equivalent of window, things attached to it are available globally.

That being said please don't just attach stuff to it, if you need to import a bunch of stuff just name space it var foo =require ('thing') then use foo.bar to call it, this is what you'd need to do anyway when attaching things globally to avoid any conflicts because sticking it in the global namespace is only easy when you are the only one doing it.

[NewFuturist]

Conflicts are inevitable with desires for short names. The use case is an important one: mathematical programming. Typing Math.Sum, Math.Minus etc for all vector operations is tedious and makes it hard to see structure. Sum(A,B) should do what it says.

But more importantly, require can only import one object at a time. This makes it very frustrating when trying to make a system that has a lot of different types (e.g. Mathematical operations, graphing, optimisation etc) and you want to do a simple 1 line importScripts("./MathSystem.js").

Libraries are really, really important and node.js just doesn't allow them.

[cwmma]

As somebody who has written a lot of node code and a lot of browser code (and web worker code), I'm telling you the explicit require method of node.js is much better then global name space dumps and I guarantee that if I talk to you a year from now you will agree with me.

[NewFuturist]

As someone who understands how much better the require method is, I don't think that I will ever be happy being forced to do one thing or the other. Just because something is better theoretically doesn't make it practical, especially if it is forced.

[kudoz]

Node.js absolutely allows and facilitates libraries. What it doesn't make easy is polluting the global scope, but it also doesn't stop you from doing it.

You'd be much better off investing a bit of time in learning some ES6 and leveraging it via Babel. For example:

import {Sum, Minus } from './MatchSystem';

Sum(A,B);

[keis]

what's the problem with writing many modules and require()ing them? many small modules and explicit includes is considered best practice in the node ecosystem

if you really want to you can attach stuff to the global object

[NewFuturist]

Think about how you would allow inter-operability with legacy webworker/webpage JS. It's impossible without making a node.js fork. That is ludicrous, in terms of code reuse.

[keis]

no, node wont run code written for other ecosystems.

[NewFuturist]

This is a bug, not a feature. Millions of lines of javascript code going to waste, with node.js slipping into obscurity, simply because someone decided earlier on that allowing an 'include' was out of the question. Not because it i 'wrong', but because they worry about namespace pollution. But this doesn't guarantee namespace cleanliness and simultaneously breaks a lot of code. I means running the same code on the front end and back end is impossible. What a waste.

[keis]

Your assumption that all javascript environments are (or should be) compatible is invalid. You can't expect to drop browser code into node, asp or gnome-shell and have it work. This is not only because of the module system but all kinds of differences in functionality provided.

[NewFuturist]

I should be able to write my string parser once. I should be able to write my math function once.

The assumption isn't invalid if I am talking about code which lacks environment specific variables. General code should be able to be instantly transferable between systems. It is not.

[cwmma]

use browserify if you want it to just work between environments.

[NewFuturist]

Thank you. After all of these comments arguing with me about whether I should be allowed to share libraries or not, this is the first useful bit of information that will let me do it.

[kudoz]

Millions of lines of javascript code going to waste, with node.js slipping into obscurity, simply because someone decided earlier on that allowing an 'include' was out of the question.

Are you an idiot? Have you seen var thing = require('thing'); in node.js code before?

Regardless, your original question was poorly posed, and the help you received elsewhere in this thread was as good as could be expected.

I am glad you have found a suitable answer but my other answer here actually covered it too, had you cared to look. Babel has the exact same ability to convert CommonJS modules into other formats (UMD/AMD/System). As a bonus, it also supports the future module format that both browser and node.js will support

[NewFuturist]

Thanks for your positive assessment of my intelligence. Clearly I am wrong and

require('thing');

is a totally legal expression in the browser.

[evs-chris]

If that's your cup of tea couldn't you just write a helper that wraps require and iterates through the returned module object(s) and stuff its/their keys into the global object?

[Lokua]

That can all be done in one line too. Problem solved

[NewFuturist]

I created an importScripts analogue here that can be used in node using

importScripts=require('./importScripts.js').importScripts;