In my endeavor to construct a TypeScript framework and bundle it using Webpack, I have encountered a perplexing issue. The problem lies in determining the appropriate "entry point" - setting it to all files results in only the final built file being accessible to the browser.
Conversely, selecting a single entry point causes only that specific class to be exposed while leaving out dependent classes within the framework. Hence, striking a balance with the entry point is crucial for seamless functionality.
Insight:
The scope of my TypeScript framework is extensive; currently comprising 140 modules, which will expand to over a thousand upon completion. Each module under the "bean" category includes an exported class along with several import statements referencing other modules within the framework.
The hierarchical folder structure is as follows:
+---src
| +---API
| +---bean
| | -- various modules --
| +---enums
| +---typings
| \---util
Each 'impl' directory contains an exported class, while parent folders house corresponding interfaces.
This framework isn't designed as a standalone application or library but is intended for users to utilize specific classes like so: `var f = new CodeListBeanImpl();`
The rationale behind these individual files stems from a defined structural hierarchy; each class serves a distinct purpose within the broader framework architecture.
Despite the scattered nature of these files across different locations, there is a lack of a definitive "entry point," impeding webpack from efficiently bundling all modules into a singular file accessible by the browser.
Here's a glimpse at my webpack configuration:
const CircularDependencyPlugin = require('circular-dependency-plugin');
const path = require("path");
const glob = require("glob");
let list = glob.sync("./src/**/*.ts");
// webpack config settings
module.exports = {
entry: list,
// other configurations...
};
The challenge arises when attempting to gather all modules comprehensively through the entry point mechanism; either choosing every file or a specific one leads to drawbacks in accessibility and functionality. It prompts me to explore alternative packers to address this limitation effectively.
For further reference, here is my tsconfig.json file governing the TypeScript compilation settings.
{
"compilerOptions": {
// compiler options details...
},
"include": ["./src/**/*.ts"]
}