We Keep Coding

Check to see if dynamic import is a module in JavaScript/TypeScript

I am working on a ScriptManager class for a project that was created many years ago. The original code read scripts from a database, and these scripts are different depending on the customer and installation (the application is a desktop app that uses Chrome Embedded Framework to display web pages). The code would read custom JavaScript code and eval() it, which of course is highly undesirable.
I am replacing this code with a ScriptManager class that can support dynamically inserted code, and the ScriptManager is capable of loading code as a module using JavaScript's dynamic import() command, or loading code as pure script by creating a script tag dynamically in the document.
My problem is that there are many different possible custom code blocks in the database, and not all are modules; some will be pure script until those can be converted to modules at a later time. My code can handle this as described above, but I need a way to detect if the script code from the database is a module, so I can either use the import() command or insert a script tag if it is not.
I am solving this temporarily by making sure any module script code has "export const isModule = true", and checking this after calling import(). This works, but any code that is pure script still results in a module variable, but with no exports in it. If possible I don't want the other developers to have to remember to add isModule = true to any modules they develop in the future.
Is there a way to check that code is a module without having to do complex analysis of the code to check if there are exports in it? Since import() still returns an object and throws no errors if there are no exports, I don't know how to detect this.
UPDATE: Here are some examples of how this is intended to work:
// Not real code, pretend that function gets the string of the script.
let code = getSomeCodeFromTheDatabase();
// Save the code for later loading.
let filename = 'some-filename.js';
saveCodeToFile(code, filename);
// Attempt to dynamically import the script as a module.
let module = await import(filename);
// If it is NOT a module, load it instead as a script tag.
// This is where I need to be able to detect if the code is
// a module or pure script.
if (!module.isModule) {
let scriptTag = document.createElement('script');
scriptTag.src = filename;
document.head.appendChild(script);
}

So if you look here How can I tell if a particular module is a CommonJS module or an ES6 module? you will see I answered a similar question.
So the thing is Sarah, modules are defined by the way that they resolve. Module-types resolving differently is what, not only makes them incompatible with one another, but it is also why we name them differently. Originally Transpillers like Babel & TypeScript were invented because of differences in ECMA-262 Specifications, and the desire to support people who didn't have the updated specifications, as well as supporting the newer features for those who did.
Today transpilers are still being used, conceptually, much the same way. They still help us maintain a single code base while supporting older specifications, and features in newer specifications, at the same time, but the also have the added benefit of being able to generate multiple different builds from a single code base. They use this to support different module types. In node.js, the primary module-type is CJS, but the future lies in ESM modules, so package maintainers have opted to dual build the projects. The use the TypeScript Compiler (aka Transpiler) to emit a CJS build, and an ESM build.
Now this is where things get complicated, because you cannot tell just by looking at a module if it CJS or ESM in this situation, **you absolutely have to inspect its code, and check if it has more than one tsconfig.json file (because it would need at-least 2 to maintain a bi-modular build (which are becoming increasingly common with the turn of each day)
My Suggestion to You:
Use well documented packages. Good packages should be documented well, and those packages should state in their README.md document, what type of package/module they are, and if the package supports more than one module type. If in doubt you can either come and ask here, or better yet, you can ask the maintainer by creating an issue, asking them to add that information to their README.md document.

You can check that there are no export after import. In chrome import() added empty default for non module.
function isNotModule(module) {
return (!Object.keys(module).length) || (!!module.default && typeof module.default === 'object' && !Object.keys(module.default).length)
}
import('./test.js')
.then((module) => {
console.log('./test.js',isNotModule(module))
})
May be it's better to check source code via regex to check if it contains export
something like this
const reg = new RegExp('([^\w]|^)export((\s+)\w|(\s*{))')
reg.test(source)

Dojo/request undefined despite require

In a script associated with an Orchard view I try to post an AJAX to server with dojo.request.post function. However, I only get esri/request, dojo/request is undefined. I call the request outside the function where the require statements reside, but there's no problem with other required packages as long as I use them in correct format. Dojo/request works in our other project, so I suspect Orchard of messing things up (the other project's dojo/request use is in a plain page, not in a view), though I would expect problems caused by it to surface earlier.
Important parts of the code:
require([ ... "dojo/request", ... ], function (... Request, ...) {
//custom init function contents
})
function sendResults(featureSet) {
//custom code processing the parameter, making uri, JSON and like
dojo.request.post(uri, {
//sending data
})
}
My razor require part in the same file contains:
Script.Require("esri/JavaScriptApi").AtHead();
Script.Require("dojo").AtHead();
Those are defined in resourcemanifest.cs:
manifest.DefineScript("esri/JavaScriptApi").SetUrl("http://js.arcgis.com/3.14/");
manifest.DefineScript("dojo").SetUrl("//ajax.googleapis.com/ajax/libs/dojo/1.10.4/dojo/dojo.js");
The error I get when I try to run the code:
TypeError: dojo.request is undefined
I've tested it in FireBug and confirmed that dojo/request doesn't exist (the same for variants, like dojo/Request), only esri/request is a function, but it has no post method.
I'm stuck here. Google search lead to "plains of sheer desperation" (page 5+) with no useful output and my co-workers don't know. Does anyone know why I can't see dojo/request and how to get it?

As far as I'm aware, dojo/request does not export a global (as modern AMD modules generally shouldn't need to), so dojo.request would never work in any context.
The appropriate way to use AMD modules is to use them within the body of a require callback (or, even better, organize your own code in AMD modules as well, and use them within a define factory function).
require([ ... "dojo/request", ... ], function (... request, ...) {
request.post(...);
})
Alternately, if you're certain dojo/request has been loaded by the time you want to use it, you could use single-argument require to reference it:
require('dojo/request').post(...);
However, this is typically not ideal and seen as a hack.
Perhaps the Introduction to AMD Modules tutorial would help to better understand optimal AMD usage.

How does es6 module loading work

I've been reading about es6 module loaders and I just don't quite understand how it works and am hoping someone can enlighten me.
In the practical workflows link above they have an example like this
System.import('app/app').then(function(app) {
// app is now the Module object with exports as getters
});
No problem with that - I get it. But then I see stuff like this
var $ = require('jquery');
and get really confused. What happens if at the time of this call jquery has not yet been transferred to the browser? Does the thread just spin? Does the browser parse your script behind-the-scenes and reform it into a callback like RequireJs does? Is what it does configurable? Are there specific limitations?
Can someone give me a rundown?

The ES6 Module Loader will fetch the source, determine dependencies, and wait until those dependencies have loaded before executing the module. So by the time the require executes, the dependency is already sitting there waiting to be executed.
When loading CommonJS through an ES6 module loader, we rely on statically parsing out the require statements from the source, and only executing the source once those requires have loaded.
In this way we can support CommonJS in the browser loaded dynamically. Circular references are treated identically to the way they are handled in Node.
The regular expressions parsing out the require are actually pretty reliable and quick, while taking into account comments and surrounding tokens. See https://github.com/systemjs/systemjs/blob/master/lib/extension-cjs.js#L10 for the one used by SystemJS.
There is one remaining limitation with this approach and that is dynamic and conditional CommonJS requires like if (condition) require('some' + 'name') aren't detected properly. This is a necessary cost though to make CommonJS behave as a fully asynchronous module format in the browser.

Why do concatenated RequireJS AMD modules need a loader?

We love RequireJS and AMD during development, where we can edit a module, hit reload in our browser, and immediately see the result. But when it comes time to concatenate our modules into a single file for production deployment, there apparently has to be an AMD loader still present, whether that loader is RequireJS itself or its smaller partner “almond” as explained here:
http://requirejs.org/docs/faq-optimization.html#wrap
My confusion is: why is a loader necessary at all? Unless you have very unusual circumstances that make it necessary for you to make require() calls inside of your modules, it would appear that a series of AMD modules could be concatenated without a loader present at all. The simplest possible example would be a pair of modules like the following.
ModA.js:
define([], function() {
return {a: 1};
});
ModB.js:
define(['ModA'], function(A) {
return {b : 2};
});
Given these two modules, it seems that a concatenator could simply produce the following text, and not burden the production server or browser with the extra bandwidth or computation required by either RequireJS or Almond.
I imagine a concatenator that produces (and I am using chevron-quotes «,» to show where the snippets from the two modules above have been inserted):
(function() {
var ModA = «function() {
return {a: 1};
}»();
var ModB = «function(A) {
return {b : 2};
}»(ModA);
return ModB;
})();
This, so far as I can see, would correctly reproduce the semantics of AMD, with a minimum of extraneous glue JavaScript. Is there such a concatenator available? If not, would I be a fool for thinking that I should write one — are there really very few code bases that consist of simple and clean modules written with define() and that never need further require() calls inside that kick off later asynchronous fetches of code?

An AMD optimiser has the scope to optimise more than the number of files to be downloaded, it can also optimise the number of modules loaded in memory.
For example, if you have 10 modules and can optimise them to 1 file, then you have saved yourself 9 downloads.
If Page1 uses all 10 modules then that's great. But what if Page2 only uses 1? An AMD loader can delay the execution of the 'factory function' until a module is require'd. Therefore, Page2 only triggers a single 'factory function' to execute.
If each module consumes 100kb of memory upon being require'd, then an AMD framework that has runtime optimisation will also save us 900kb of memory on Page2.
An example of this could be an 'About Box' style dialog. Where the very execution of it is delayed until the very last second as it won't be accessed in 99% of cases. E.g. (in loose jQuery syntax):
aboutBoxBtn.click(function () {
require(['aboutBox'], function (aboutBox) {
aboutBox.show();
}
});
You save the expense of creating the JS objects and DOM associated with the 'About Box' until you are sure it's necessary.
For more info, see Delay executing defines until first require for requirejs's take on this.

The only real benefit is if you use modules across sections so there's a benefit to caching modules independently.

I had the same need, so I created a simple AMD "compiler" for that purpose that does just that. You can get it at https://github.com/amitayh/amd-compiler
Please note that it has many features missing, but it does the job (at least for me). Feel free to contribute to the codebase.

In case you compile you code with require.js into a single large file for production, you can use almond.js to completely replace require.
Almond only handles the module references management not the loading itself which is no longer needed.
Be careful of the restrictions almond imposes in order to work

There is no reason why there couldn't be a build tool such as the one you propose.
The last time* I looked at the optimizer's output, it converted the modules to explicitly named modules, and then concatenated those together. It relied on require itself to make sure that the factory functions were called in the right order, and that the proper module objects were passed around. To build a tool like you want, you would have to explicitly linearize the modules -- not impossible, but a lot more work. That's probably why it hasn't been done.
I believe** that the optimizer has a feature to automatically include require itself (or almond) into the built file, so that you only have to have one download. That would be larger than the output of the build tool you want, but otherwise the same.
If there was a build tool that produced the kind of output you're asking for, It would have to be more careful, in case of the synchronous require, the use of exports instead of return, and any other CommonJS compatibility features.
*That was a few years ago. 2010, I think.
**But can't seem to find it right now.

Getting started with Yabble--browser-side CommonJS module loading

Is anyone familiar with Yabble or other browser-side CommonJS loaders?
I'm experimenting with Node.js and would very much like to create Javascript modules which can be used interchangeably on the server side and the client side. This may end up being more a "because it's awesome" kind of thing more so than "because it's practical and useful" kind of thing.
As such, I'm basically trying to get the CommonJS require() method to work on the browser-side, which is exactly what Yabble is supposed to do. I don't really know where to start with it though. I can't seem to find any documentation other than what's found in Yabble's Github readme, and that's not helping much.
Essentially all I've done is put this in an HTML page...
<script src="yabble.js"></script>
<!-- Uses require -->
<script>
require.setModuleRoot('http://localhost:8030/')
my_module = require('my_module')
</script>
But anytime I call the require() function all I get a Synchronous require() is not supported. exception thrown.
Can someone help me get started? Where am I supposed to load yabble.js where am I supposed to call require? Is there a special way to run my Javascript modules?

When loading Javascript code that will need to use the require() function into the browser, the entry point into that code must be the require.run() function.
e.g., Good:
<script src="yabble.js"></script>
<script>
require.setModuleRoot('http://localhost:8030/')
require.run('my_module') // <-- Uses require() function somewhere
</script>
e.g., Bad (Will get the Synchronous require() is not supported error):
<script src="yabble.js"></script>
<script src="http://localhost:8030/my_module.js"></script> <!-- <== Use's require function somewhere -->
FYI, it's pretty nifty how Yabble does this. It will actually statically analyze your Javascript source code, I think basically just using a regular expression to look for the require() method, and then try to pull that .js script from the server, then it does the same static analysis of that .js script, and on and on.
This can be particularly confusing because it will actually load those .js scripts even if the control logic would mean program flow would never reach the require() function. e.g., if you had...
if (False) { require('some_module'); }
... Yabble will still load this module.

Synchronous loading of modules in the browser is problematic. A construct like:
var x = require('something_remote.js')
Implies that the browser will halt your code (i.e. block), go and fetch the remote file, parse it, and then return to you the exports. But this does not jive with the single-threaded browser environment - we would be halting the main JavaScript thread (and thus page interactivity for the user) on the performance of the network. So browsers have evolved against this scenario, to favor async loading on their own schedule. There is some good discussion here:
http://www.sitepen.com/blog/2010/07/16/asynchronous-commonjs-modules-for-the-browser-and-introducing-transporter/
One pattern which might work here is that a require() implementation does synchronously block, fetches the file via XHR and then evals it, but that seems to run against all the browser support/infrastructure for async file-based loading. Also I'm curious what implications that would have for the cross-domain primitive of browser security.
So in order to fit the browser async loading model, we'll need to use a callback mechanism like:
require("something.js", function () { // called later, after something.js has loaded! })
It looks like RequireJS is doing this:
http://requirejs.org/docs/start.html
Perhaps give that a shot?
JavaScript environments like NodeJS etc - built with the provision of loading "local" modules from disk, instead of foreign network hosts - can do the synchronous load.
I would greatly appreciate any corrections from JS experts :-)