@ms-cloudpack/bundler 0.25.33 → 0.25.34
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +6 -58
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -1,48 +1,12 @@
|
|
|
1
1
|
# @ms-cloudpack/bundler
|
|
2
2
|
|
|
3
|
-
This library provides an abstraction on bundling a package, assuming that the package is conformant.
|
|
3
|
+
This library provides Cloudpack's implementation of an abstraction on bundling a package, assuming that the package is conformant.
|
|
4
4
|
|
|
5
5
|
Rather than directly depending on Webpack, rollup, or esbuild with large amounts of custom configuration, having an abstraction around bundling provides constraints around having common inputs/outputs.
|
|
6
6
|
|
|
7
7
|
This enforces the code follow consistent constraints, while also ensuring the output can be consumed in the browser or in node depending on supported environments.
|
|
8
8
|
|
|
9
|
-
Abstraction also allows us to use the right tool for the job. The right tool depends on priorities and capabilities. For dev builds we want the fastest tool, while for production we want optimal output.
|
|
10
|
-
|
|
11
|
-
## Usage
|
|
12
|
-
|
|
13
|
-
### `async function bundlePackage(options)`
|
|
14
|
-
|
|
15
|
-
```tsx
|
|
16
|
-
import { bundlePackage } from '@ms-cloudpack/bundler';
|
|
17
|
-
|
|
18
|
-
async function start() {
|
|
19
|
-
const result = await bundlePackage({
|
|
20
|
-
packagePath: process.cwd(),
|
|
21
|
-
outputPath: path.join(process.cwd(), 'dist'),
|
|
22
|
-
outputType: 'library',
|
|
23
|
-
});
|
|
24
|
-
|
|
25
|
-
console.log(result);
|
|
26
|
-
}
|
|
27
|
-
|
|
28
|
-
start();
|
|
29
|
-
```
|
|
30
|
-
|
|
31
|
-
### `bundlePackage` options
|
|
32
|
-
|
|
33
|
-
| Name | Type | Description |
|
|
34
|
-
| ----------- | ------------------------------ | ------------------------------------------------------------ |
|
|
35
|
-
| packagePath | string | Path to the package root where package.json lives. |
|
|
36
|
-
| force | boolean | Bypasses the cache to create bundles. |
|
|
37
|
-
| hashFrom | `"package-version"` \| `"git"` | Determines how the cache key is computed for bundle results. |
|
|
38
|
-
| output | `"library"` \| `"app"` |
|
|
39
|
-
|
|
40
|
-
### Return object
|
|
41
|
-
|
|
42
|
-
| Name | Type | Description |
|
|
43
|
-
| --------- | ---- | ----------- |
|
|
44
|
-
| stats |
|
|
45
|
-
| outputMap |
|
|
9
|
+
Abstraction also allows us to use the right tool for the job. The right tool depends on priorities and capabilities. For dev builds we want the fastest tool, while for production we want optimal output.
|
|
46
10
|
|
|
47
11
|
## Details
|
|
48
12
|
|
|
@@ -52,24 +16,8 @@ The Cloudpack bundler abstraction is simple and constrained on purpose:
|
|
|
52
16
|
2. Emits standard ESM bundle.
|
|
53
17
|
3. Leverages package.json and convention as much as possible:
|
|
54
18
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
- library mode - produces a bundle of source which externalizes dependencies and is consumable by the target (browser or node) which
|
|
58
|
-
can resolve the dependencies through an import maps in the browser or through module resolution in node. The source is unminified.
|
|
59
|
-
- production mode - produces a bundle of source which includes dependencies and is also similarly consumed.
|
|
60
|
-
|
|
61
|
-
### Package requirements
|
|
62
|
-
|
|
63
|
-
#### Discovering entry points
|
|
64
|
-
|
|
65
|
-
Entry points are discovered by analyzing the package.json. This ensures only explicit entries are bundled.
|
|
66
|
-
|
|
67
|
-
### ESM output
|
|
68
|
-
|
|
69
|
-
### Considerations
|
|
70
|
-
|
|
71
|
-
#### Leverage existing task runners
|
|
72
|
-
|
|
73
|
-
Under the hood, if we want to separate the process into multiple steps, we may consider using task helpers like `just-scripts` or `heft` to execute things in the right order. This might help
|
|
19
|
+
There are three output modes:
|
|
74
20
|
|
|
75
|
-
|
|
21
|
+
- library mode - produces a bundle of source which externalizes dependencies and is directly consumable by the target (browser or node), which can resolve the dependencies through an import map in the browser or through module resolution in node. The source is unminified.
|
|
22
|
+
- production mode - produces a bundle of minified source which includes dependencies and is also similarly consumed.
|
|
23
|
+
- development mode - like production mode, but not minified.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@ms-cloudpack/bundler",
|
|
3
|
-
"version": "0.25.
|
|
3
|
+
"version": "0.25.34",
|
|
4
4
|
"description": "An abstraction to bundle source code.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
}
|
|
15
15
|
},
|
|
16
16
|
"dependencies": {
|
|
17
|
-
"@ms-cloudpack/bundler-ori": "^0.2.
|
|
17
|
+
"@ms-cloudpack/bundler-ori": "^0.2.69",
|
|
18
18
|
"@ms-cloudpack/bundler-rollup": "^0.4.14",
|
|
19
19
|
"@ms-cloudpack/bundler-rspack": "^0.3.9",
|
|
20
20
|
"@ms-cloudpack/bundler-webpack": "^0.3.9",
|