> For the complete documentation index, see [llms.txt](https://notes.lirenxn.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notes.lirenxn.com/2020/wk-notes-01-16-bundling-treeshaking-1.md).

# Wk-notes-01-16-Bundling-Treeshaking-1

Bundle a **cjs** build, a **es** build, a **esm** build,

and using rollup to build a **umd** build 

and in `package.json`, the `main` entry is point to `cjs` dir, `module` entry is point to `esm` dir

1. What’s the difference between `es` and `esm` ? seems difference is in the `@babael/preset-env`

   > es is for browser script tags, esm is for basically not transpiling. the main difference is the level of transpiling you need to do a lot more to support the shittier versions of browsers that first supported \<script type="module>
2. What’s babel-env ‘production’ and ‘production-umd’ ?

   > nothing really
3. Where is the output of `npm run build:umd`?

   > Checkout the actual code for the command, say `rollup.config.js`, which just use some process to output a umd bundle **(umd single file)**. And babel don't support umd bundling.
4. Why are we bundling in different module systems ?

   > To support different ways of import/require. Preact have this <https://unpkg.com/browse/preact@10.2.1/dist/> different. **lodash** also enables different build
5. Why do we symlink `lib/node_module` in `build:prepare-bundle`?

   > because CI needs to deploy with `semantic-release` and its too slow to `cp` a directory
6. Which part of this new way of bundling enable treeshaking ?

   > esm, and specific path based imports
7. How do we consume this bundle from `widget` ? What changes when we consume it w/ different module solution?

   > how i've done it in my PR's so far but instead its now going to be like `import Button from '@qantasairways/runway/components/Button';`