I sugguest outFiles, who can act M: N merge

[samchon]

Ordinary "outFile" is

M: 1 Merging

When we write lots of codes that are difficult write in few TS files, however the codes should be merged into a single JS file, then we can take one of them:

1. Use module system like CommonJS or RequireJS
2. Use outFile

The outFile parameter in tsconfig.json lets TSC to merge multiple ts files into a single js file.

{
    "compilerOptions": {
        "target": "es5",
        "outFile": "include/something.js"
    },
    "files": ["first.ts", "second.ts", "third.ts", "fourth.ts"]
}

M: N Merging?

The outFile merges into only a single JS file. If someone wants to merge multiple TS files into multiple JS files (less fewer), then how should do? Using module system is a standard solution now, But I think the outFiles can be an alternative solution.

1. Use module system like CommonJS or RequireJS
2. (Suggestion) Use outFiles

Specification

Example

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs"
    },
    "outFiles": {
        "list.js": ["src/list/list.ts", "src/list/list_iterator.ts", "src/list/list_reverse_iterator.ts"],
        "tree_map.js": ["src/tree_map/tree_map.ts", "src/tree_map/rb_tree.ts"],
        "hash_map.js": ["src/hash_map/hash_map.ts", "src/hash_map/hash_buckets.ts"],
        "algorithm.js": ["src/algorithm/"],
        "filesystem.js": ["src/filesystem/"],
        "functional.js": ["src/func_*.ts"]
    }
}

Using module system is possible

Not like outFile, I wish to using module system is possible in the outFile.

Arrange JS files to be generated and specify TS files to be merged

    "outFiles": {
        "list.js": ["src/list/list.ts", "src/list/list_iterator.ts", "src/list/list_reverse_iterator.ts"],
        "tree_map.js": ["src/tree_map/tree_map.ts", "src/tree_map/rb_tree.ts"],
        "hash_map.js": ["src/hash_map/hash_map.ts", "src/hash_map/hash_buckets.ts"]
    }

To act M: N merging, declare an object named outFiles and arranges JS files to be generated and TS files to be merged. Path of JS files are key_type and Array of TS files are value_type.

Specifying Directories

    "outFiles": {
        "algorithm.js": ["src/algorithm/"],
        "filesystem.js": ["src/filesystem/"],
        "to_be_generated.js": ["some_directory/", ...]
    }

Not only specifying TS files, but also specifying a directory would be better. When a directory is referenced in the Array, then all the TS files in the directory will be merged into the target JS file.

Conditional Specification

    "outFiles": {
        "functional.js": ["src/func_*.ts"]
    }

I think not only using the exact, pull path of TS files, but also using the conditional specification would be better.

Comparing with Module System

Convenient Modularization

M: N merging, it is also possible through the module system. However, the outFiles can be more convenient in some cases.

Let's assume that you're going to develop a library (I assume that the library is STL). Some modules (<algorithm> and <functional>) of the library has hundreds of global functions.

You created dozens of TS files because codes of the global functions are very long. Now, you should merge the dozens of TS files into JS files (std/algorithm.js, std/functional.js). With the module system, you may write such code:

// algorithm.ts
export * from "./algorithm/alg1";
export * from "./algorithm/alg2";
export * from "./algorithm/alg3";
export * from "./algorithm/alg4";
...

Doesn't it seem annoying and even danger? outFiles will be helpful for this case. Note that, outFiles is not a conception has exclusive relationship between the module system. outFiles can be harmonized with the module system.

API Documentation

To generate clean and neat API documents (unless writes API documents by hand manually), smaller number of modules are much favorable.

If not using the Module System

<script src="include/std/vector.js"></script>
<script src="include/std/list.js"></script>
<script src="include/std/map.js"></script>
<script src="include/std/algorithm.js"></script>

Developing web application without module system, but including JS files directly, it's not normal case in nowadays. However, it's not extinct yet.

For the minorities, not only providing outFile method, but also providing the outFiles method will be much helpful.

[RyanCavanaugh]

Nice write-up and we would probably use this internally if it existed. But we're generally pushing people toward using modules and external bundlers to produce output files and hope that out as a concat method eventually fades away from major use, so we're not looking to invest in this upfront. But if other people would find the useful (please 👍 we can revisit).

[samchon]

Thanks for responding. I'm developing some web applications that cannot avoid using many Workers. The Worker requires an independent JS file and the Worker's file has its own specific import statement; importScripts.

importScripts
(
    "tstl.js",
    "samchon.js",
    "statistics.js",
    "geometry.js"
);

In the web development and using Worker, then I think the outFiles will be much helpful than ordinary module system like CommonJS.

[muenchris]

I like the proposal as well. My biggest issue is "Debugging" as the Visual Studio debugger does only allow me to debug the files in one (VS) project. I therefore have to make a decision to have all my TS files compiled into separate JS files or combine them ALL into one JS File. I cannot create layers of multiple TS files compiling into multiple (but fewer) JS files.

The proposal on here would allow me to create layers like "Core.JS", "Communication.JS", "UX.JS" (outfiles) and each of them having multiple TS files.

I can then debug my project easy in VS.

Right now I have a primary TS project with all my "Stack" TS files compiling into one JS file and a second project with my higher level "stack API consuming" TS files. The Index.html loads both resulting JS files but I can only debug either the stack or the consumer - not both (across the two projects).

The multiple outfiles solution would help me with this layered structure (without using any other tools that merge files and make debugging impossible).