Develop Reference

Import, Require? How to Mash Javascript Files Together?

This is vague - I apologize in advance, I am trying to be as succinct as I can with my limited understanding, while exposing my potentially incorrect assumptions.
I have a website that's literally one huge HTML file. It runs scripts defined in-line in a <scripts> tag.
My goal is to move all the scripts into individual .js files and pull them into index.html (or into one another where required). I am familiar with the usage of Node's require and I am familiar with import, as used in Angular. I stress usage because I don't really know how they work.
Assumption 1: I cannot use require - it is purely for Node.js. The reason I bring it up is that I am pretty sure I have seen require in AngularJS 1.5 code, so assuming makes me uncomfortable. I am guessing this was stitched together by WebPack, Gulp, or similar.
Assumption 2: I should use import, but import only works with a URL address, if I have my .js hosted on a server or CDN, it will be be pulled. BUT, I cannot give local pathing (on the server) here - index.html will NOT automatically pull in the dependencies while being served. I need npm/Webpack/other to pre-compile my index.html if I want the deps pulled in on the server.
Assumption 3: Pre-compiling into a single, ready-to-go, html file is the desired way to build things, because the file can be served quickly (assuming it's ready to go). I make the assumption with the recent trend of serving Markdown from CDNs, the appearance of the JAMstack, and the number of sites using Jekyll and such (though admittedly for traditional Jekyll sites).
Assumption 4: I also want to go to Typescript eventually, but I assume that changes nothing, since I will just pull in TS to compile it down to .js and then use whatever solution I used above
Question: If it's clear what I am trying to do and what confuses me, is a decent solution to look into npm/Webpack to stich together my .js files? What would prepare them for being stiched together, using import/export? If so, is there an example of how this is usually done?

As you mentioned, require cannot be used for your purposes, since it is a part of CommonJS and NodeJS's module system. More info on require can be found here: What is this Javascript "require"?
Import is a ES2015 standard JS syntax. But ES2015 standard and everything above it has very limited browser support. You can read more about it here: Import Reference
However, you can still code in the latest standard (thereby enabling the use of import/export etc.,) and then transpile the code to be able to run on the browser. Inorder to do this, you require a transpiler. You can refer Babel which is one of the most popular transpilers : https://babeljs.io/
For your exact purpose, you need to use a module bundler. Webpack/Rollup etc., are some popular module bundlers. They can automatically identify all the JS files referenced through import, combine them and then transpile code to be able to run on the browser (they also use a transpiler) and produce a single JS file (or multiple, based on your configurations).
You can refer the getting started guides of Webpack: https://webpack.js.org/guides/getting-started/
or RollupJS: https://rollupjs.org/guide/en#quick-start

Exposing a Node.js library via ambient TypeScript

In an attempt to simplify the use of pg-promise library for those who prefer coding for Node.js in TypeScript, I created a complete set of ambient declarations needed to fully represent the library, and included it into the distribution in a separate folder.
However, being not a proficient TypeScript developer, I'm stuck in my research for best practices in doing this sort of thing.
I want to know if simply including ambient declarations in a separate folder is sufficient for developers to start using it right away, without running into problems.
I also want to write some sort of a short guideline for how to use those TypeScript declarations, but frankly, I am myself not doing a good job at it, even though the declarations all seem correct.
So my question is then:
Is there any article or a guideline to explain it to Node.js developers how to do it with the latest version of TypeScript? (best practices for exposing a Node.js library via TypeScript)
UPDATE
One of the very first problems I'm running into, trying to use such ambient declarations directly, from a TypeScript file - the main file refuses to find the two dependent ones, no matter what change I try, it keeps on saying Cannot file module....
UPDATE
I've tried countless per-mutations for how to re-declare the library, and yet I haven't been able to get it work after all.
I've tried to move dependent declarations inside one file, using in their own namespace and as an inner namespace.
I've tried different combinations of ambient declarations with classic declarations.
I've tried changing modules into namespaces.
It only brought me to a point of desperation and dislike toward TypeScript. All I want is to make my Node.js library readily usable for TypeScript developers.
Most of the time I've running into issues where it says that my TypeScript is not a module. In other cases it couldn't find some types. Nothing but trouble. Please somebody help me with this.
UPDATE
Should I even include TypeScript with the library or should it be published on Definitely Typed instead?

How to unextend Extendables framework, keeping just the logger and Jasmine test functionalities

I'm using a nice framework for Adobe ExtendScript called Extendables. I forked the project here: https://github.com/daluu/Extendables
A problem though is that in some ways using the framework is worse than not because the framework extends javascript objects with more functionality. And on an initial review of the code files, they seem rather interdependent such that it will take some work to uncouple the strict dependencies to make it optional/configurable to load only what you need and skip the rest in case of issues with particular features (i.e. you can just not load/include what you don't use - I don't think that's currently possible, although I might be mistaken). See the issue tracker in my project for details but in general the issues encountered using the full framework is failure of try/catch blocks and object iteration includes unintented properties.
For me, I'd just like at a minimum to make all functionality optional and just load the logger and Jasmine test framework as those are the only two feature/modules that I really use with Extendables. I don't care for the extensions to strings, files, object, arrays, etc.
As I'm a novice in javascript/ExtendScript, and this is not a trivially simple javascript framework, I could use suggestions on how to decouple the dependencies so that every module (baring it's dependendencies) can be optionally loaded, and where there are dependencies we can group into sets as in you can load or not load this set of features.
Sorry that I can't include code snippets as its too much to post, you can find it in my Github fork.
Not sure if this is best StackExchange site to post but starting here.

You should be able to extract the log module from this file:
https://github.com/daluu/Extendables/blob/master/core-packages/logging/lib/index.jsx
Try to use it like this (not tested):
#include "core-packages/logging/lib/index.jsx"
Log.debug("Log this");
You might need to adjust some things in there e.g. Folder.extendables does not exist in ExtendScript. Also exports.Log at the end will throw an error.

Comparison of methods to create a toolchain: JS modules / loader / build

In the process of evaluating the various approaches available to developers to use javascript modules, module loaders and build tools, i'd like some suggestions on what tools you use, and why.
I'm currently after something that is able to:
-encourage modular code
-allow features to be added based on necessity to a given module [think mixins/inheritance]
-produce a BUILD that contains a development release, and at the very minimum a production release with different layers (say, i want a layer [a script] which contains my bootstrap code, module 1, 2 and 3; and then another layer which contains modules 4,5 and 6. This way I can defer loading of code based on what's actually going on in the application.)
-Work [when built for production] in an extremely low bandwidth scenario, with xfer speeds of 1kbps and high latency (think worst case mobile connection over GPRS to get the picture).
I've seen the following:
Using prototype inheritance, as in:
myNS.thing = function(){};
myns.thing.prototype = {
something: "foo"
}
Which can be built by simply taking the contents of this script, and appending it to the next one one wants to include in a production optimized package as a single script. Loaders in this case are simple script tag injections/eval's or similar, based on a known file.
I've also seen other approaches, such as:
function(){
return function(){
something: "foo"
}
}();
Building this already gets more complex because one has to manipulate the script, removing the wrapping self executing function and combining the return values into one object. I am not aware of an "easy" way to use available build tools. The loader approach works the same as above.
Both of these approaches lack dependencies.
Then we have AMD:
define("mymodule", ["dep1"], function(dep1){
return {something: dep1}
});
Some might be nauseated by its indenting, and its "ceremony", but still its quite effective, the google closure compiler knows about it natively, it knows about dependencies, and seems to have widespread adoption across the board. There are a bunch of module loaders available for it (https://docs.google.com/spreadsheet/ccc?key=0Aqln2akPWiMIdERkY3J2OXdOUVJDTkNSQ2ZsV3hoWVE#gid=2) and quite a few build tools as well.
What other options do you know of, or have you seen used in production?
As said, i'm interested in a combination of code syntax, loader tools and build tools. These three must exist and be working together properly. The rest is an academic excercise i'm not interested in.

I personally use RequireJS, an AMD solution. If I'm whipping up quick proof-of-concepts I won't bother setting that up, but the most common source/dep-mapping solutions I know of now include:
RequireJS
CommonJS
Google Closure
YepNope (a conditional loader, can be used in combination with the others)
I have started a boilerplate that uses Require in combination with Backbone to get all the ugly setup code out of the way:
https://github.com/nick-jonas/assemblejs
So you can type assemble init to scaffold the basic project and assemble build to run the compilers and get a final production-ready build.

You might be interested in looking at Grunt a command line tool with various modules for building javascript projects. It uses npm for dependencies and it will work with amd modules, but you can just configure it to concatenate the files you need using grunt-buildconcat.

Custom dojo build at functions level

We are creating a javascript library from scratch and we need some utilities functions, just like what dojo provides, e.g. xhr wrapper, simple inheritances and array manipulation, etc. We don't want to write these functions ourselves from scratch, but we also don't want to just copy and paste code from dojo.
Dojo provides the custom build mechanism, but it works on the module level. For example, in the custom build, you can specify to only add the lang module in the dojo base. But we may only need the dojo.hitch function in the lang module, but not the dojo.clone function that also included in the lang module. We have a tight constraint on the size of the library file, so we need to remove any unused code.
What we are seeking is a way to extract certain functions from a module and build these functions into a single javascript file. For example, say we need dojo.mixin, dojo.declare and dojo.hitch functions, then these functions' declaration and their dependent inner functions should be built into a single file.
Any suggestions?
Update from my test result
Thanks Stephen Chung for your great suggestion on how to solve this problem.
So basically I created a custom dojo build with four modules : dojo._base.xhr, dojo._base.json, dojo._base.declare and dojo._base.lang. The built dojo.js file is 149kb, after using Google Closure compiler with advanced mode, the size has reduced to 24kb and the unused functions have been removed. If we want to keep some functions, just add another javascript file like below:
window['dojo'] = dojo;
window['dojo']['requireLocalization'] = dojo.requireLocalization;
window['dojo']['moduleUrl'] = dojo.moduleUrl;
and compile it with dojo.js.
Unfortunately the size is still a little bigger. We have a size limit of 40k in total. But this is still a very good solution for other cases.

Dojo Core is written in a very compact manner, with a lot of cross callings (i.e. one function calling other functions) in order to save download bytes and reduce code size.
Therefore, you need a minimal set of Dojo Core functions, together with the functions that it calls.
In other words, what you need is a build that includes Dojo Core, but then removes any dead-code that is never called.
I'd suggest that you don't go about creating a minimal-footprint library by writing it from scratch yourself. What you need is to use the Closure Compiler's Advanced Mode to process your Dojo application. It removes dead code, optimizes the entire app, and fully obfuscates it.
And yes, it is possible to use the Closure Compiler with Dojo in Advanced Mode -- Dojo is probably the only popular library that can do it. Read it here.
Some statistics: A Closure-compiled Dojo app is typically around 25-30% smaller than the equivalent Dojo app in a Shrinksafe build. It depends on how many Dojo Core features you use -- typically you may reduce Dojo Core up to 40% of the original size (i.e. reduce code size by up to 60%) from dead code removal alone. Further reductions are more difficult, as you may have to start removing features like the Dojo loader etc.

Are you fixed on dojo? Google's closure library offers a very similar package management system to dojo, as well as all the necessary scripts and tools you need to compile the javascript down to a single "executable". The closure library compiler is arguably one of the most advanced javascript minifiers you will find so if tight, concise javascript is your goal, this tool could help tremendously.