An unknown land of creating libraries

Transcript

1. September 2018 Title on the way Sit back and relax Who am I? "
2. Thanks to our sponsors!
3. Introduction!!
4. The hardest part of the talk are the introductory slides
5. Then, Title of the talk - Author Name Slide 1: Talk Begins Slide 2:
6. Now, Author Name Slide 1: Title of the talk Slide 2: Slide 3: : Talk Begins Slide 8: : :
7. Who am I? Not the real question

8. Real Questions? 

9. What did you use to make the presentation? Which VSCode theme is that? Which font family is that?
10. What did you use to make the presentation?
 - Keynote Which VSCode theme is that?
 - Material Which font family is that?
 - Operator mono
11. Kamlesh Chandnani Namaste $ Alicante %
12. Bengaluru, India
13. @_kamlesh_
14. <PrincipalFrontendEngineer/>
17. Co Organize ReactJS ⚛ Meetup Bangalore
18. Title?
19. An unknown land of creating libraries
21. TL;DR: I don’t know what I’ll be talking 
 "
23. Let’s Begin
24. What is a package? A package is a namespace that organises set of related files/modules that are responsible of doing some task. In node.js every package has a package.json which has the metadata about that package
25. What is a module? A module is anything that can be loaded with require/import in a Node.js program. import React from 'react'; const webpack = require('webpack');
26. Why will someone create a module?
27. The simplest answer is we all are lazy and so we don’t want to write the same thing over and over again. Hence, we create packages that can be published as modules so that other people can use them directly.
28. So now since we know the “Why” part of it let’s address the “How” part of it
29. Why JS module system? Various JS Module Systems +
30. // file1.js const makeMessage = (message) => { return `Message: ${message}`; } // file2.js const showMessage = () => { const message = makeMessage('Calling makeMessage’) // makeMessage is undefined console.log(message); }
31. In JavaScript, we can’t share code between multiple files natively.
32. // file2.js const makeMessage = (message) => { return `Message: ${message}`; } const showMessage = () => { const message = makeMessage('Calling makeMessage') console.log(message); }
33. This was just a small piece of code, but imagine if you have big massive application and you’re writing everything in one file.
35. Issues 1. Messy Code 2. Fucked up Dependency management. 3. Refactoring becomes painful.
36. JavaScript Module Systems solves exactly these problems.
37. What are the different types of JS module systems? Various JS Module Systems +
38. 1. CommonJS 2. AMD: Async Module Definition 3. UMD: Universal Module Definition 4. ECMAScript Harmony (ES6) Various JS Module Systems +
39. CommonJS Various JS Module Systems + // File log.js function log(){ console.log('Example of CJS module system'); } // expose log to other modules module.exports = { log }; // File index.js var logModule = require('./log'); logModule.log(); • No static analyzing, as you get an object, so property lookup is at runtime. • You always get a copy of an object, so you won’t get live changes from the module itself. • No tree shaking, because when you import you get an object.
40. CommonJS Various JS Module Systems + //------ lib.cjs.js ------ let counter = 3; const incCounter = () => { counter++; } module.exports = { counter, incCounter } //------ main.js ------ const lib = require('./lib.cjs'); // The imported value `counter` is not live console.log(lib.counter); // 3 lib.incCounter(); console.log(lib.counter); // 3
41. CommonJS Various JS Module Systems + // File log.js function log(){ console.log('Example of CJS module system'); } // expose log to other modules module.exports = { log } // File index.js var logModule = require('./log'); logModule.log(); • No static analyzing, as you get an object, so property lookup is at runtime. • You always get a copy of an object, so you won’t get live changes from the module itself. • No tree shaking, because when you import you get an object.
42. AMD: Async Module Definition Various JS Module Systems + // File log.js define(['logModule'], function(){ // export (expose) foo for other modules return { log: function(){ console.log('Example of AMD module system'); } }; }); // File index.js require(['log'], function (logModule) { logModule.log(); }); • Implemented by RequireJs • Complex Syntax • Used for dynamic loading of modules
43. UMD: Universal Module Definition Various JS Module Systems + // File log.js (function (global, factory) { if (typeof define === "function" && define.amd) { define(["exports"], factory); } else if (typeof exports !== "undefined") { factory(exports); } else { var mod = { exports: {} }; factory(mod.exports); global.log = mod.exports; } })(this, function (exports) { "use strict"; function log() { console.log("Example of UMD module system"); } // expose log to other modules exports.log = log; }); • Combination of CommonJs + AMD (that is, Syntax of CommonJs + async loading of AMD)
44. ECMAScript Harmony (ES6) Various JS Module Systems + // File log.js const log = () => { console.log('Example of ES module system'); } export default log // File index.js import log from "./log" log(); • Much cleaner. • Import via “import” and export via “export” • Static analyzing — You can determine imports and exports at compile time (statically) . This opens up doors for Tree Shaking. • When you import, you get back actual value, so any change is a live changes in the module itself.
45. ECMAScript Harmony (ES6) Various JS Module Systems + //------ lib.es.js ------ export default class Counter { static counter = 3; } export const showCounter = () => { console.log('counter', Counter.counter); } //------ main.js ------ import Counter, { showCounter } from './lib'; // The `Counter.counter` is live console.log(showCounter()) // 3 Counter.counter++ console.log(showCounter()) // 4
46. All of these module systems have one thing in common: they allow you to import and export stuff Various JS Module Systems +
47. What module system to target? Various JS Module Systems + Target
48. Various JS Module Systems + Target Courtesy $: Addy Osmani
49. Various JS Module Systems + Target 500 million internet users in India ~ 52.4% users are on 3G and slower networks
50. Let’s Code +
51. export default class ecmascript { showMessage = () => { console.log('Welcome to the world of ES'); }; } ES RAW
52. export default class ecmascript { constructor() { this.showMessage = () => { console.log('Welcome to the world of ES'); }; } } ES (“modules”: false)
53. export default class ecmascript { constructor() { this.showMessage = () => { console.log('Welcome to the world of ES'); }; } } ES CJS exports.__esModule = true; function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function”); } } var ecmascript = function ecmascript() { _classCallCheck(this, ecmascript); this.showMessage = function () { console.log('Welcome to the world of ES'); }; }; exports.default = ecmascript; (“modules”: false) (“modules”: “commonjs”)
54. export default class ecmascript { constructor() { this.showMessage = () => { console.log('Welcome to the world of ES'); }; } } ES CJS exports.__esModule = true; function _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError("Cannot call a class as a function”); } } var ecmascript = function ecmascript() { _classCallCheck(this, ecmascript); this.showMessage = function () { console.log('Welcome to the world of ES'); }; }; exports.default = ecmascript; # Type Size (Bytes) 1 RAW 112 2 ES 146 3 CJS 398 (“modules”: false) (“modules”: “commonjs”)
55. Can you afford it?
56. Considering the fact that you’re building your code as ES target but still what about unused code?
57. Tree Shaking •It is a term commonly used in the context of JavaScript for live code inclusion(import whatever is required). "
 •It relies on the static structure of ES module syntax, that is, “import” and “export”.
59. Tree Shakeable ✅ // File shakebake.js const shake = () => console.log('shake'); const bake = () => console.log('bake'); //can be tree shaken as we export as es modules export { shake, bake }; // File index.js import { shake } from './shakebake.js' // only "shake" is included in the output
60. Tree Shakeable ✅ // File shakebake.js const shake = () => console.log('shake'); const bake = () => console.log('bake'); //can be tree shaken as we export as es modules export { shake, bake }; // File index.js import { shake } from './shakebake.js' // only "shake" is included in the output Non Tree Shakeable ❌ // File shakebake.js const shake = () => console.log('shake'); const bake = () => console.log('bake'); //cannot be tree shaken as we have exported an object export default { shake, bake }; // File index.js import { shake } from './shakebake.js' // both "shake" and "bake" are included in the output
61. Various JS Module Systems + Target “Ship whatever is needed”
62. Various JS Module Systems + CommonJS ESM Target Comparison # CommonJS ESM Tree Shaking ❌ ✅ Async Module Loading ❌ ✅ Static/Compile- time analyzing ❌ ✅ Import/require gives actual value of the module? ❌ ✅
63. Various JS Module Systems + CommonJS ESM Target There’s more in ESM! • <script type=“module”> ➡ deferred by default.
 • Even if we add the <script type=“module”/> multiple times on the page it gets executed just once.
 • Global variables is global to that module (lexical scope) and not to the window scope.
 • You can optimize the delivery of your modules further by using <link rel=“modulepreload”> PS: This is still anexperimental feature.
64. <html> <head> <script type="module" src="//unpkg.com/something.mjs"></script> <script type="module" src="//unpkg.com/something.mjs"></script> <script type="module" src="//unpkg.com/something.mjs"></script> <script type="module" src="//unpkg.com/something.mjs"></script> <!-- The above gets executed just once --> <script src="//unpkg.com/something.js"></script> <script src="//unpkg.com/something.js"></script> <script src="//unpkg.com/something.js"></script> <!-- The above gets executed thrice --> </head> </html>
65. Various JS Module Systems + CommonJS ESM Target What Else in ESM? • <script type=“module”> ➡ deferred by default.
 • Even if we add the <script type=“module”/> multiple times on the page it gets executed just once.
 • Global variables are global to that module (lexical scope) and not to the window scope.
 • You can optimize the delivery of your modules further by using <link rel=“modulepreload”> PS: This is still anexperimental feature.
66. <html> <head> <script type="module"> const testModule = "This is a module" </script> <script type="module"> console.log({ testModule }) // testModule is undefined </script> </head> </html> Scope
67. Various JS Module Systems + CommonJS ESM Target What Else in ESM? • <script type=“module”> ➡ deferred by default.
 • Even if we add the <script type=“module”/> multiple times on the page it gets executed just once.
 • Global variables are global to that module (lexical scope) and not to the window scope.
 • You can optimize the delivery of your modules further by using <link rel=“modulepreload”> PS: This is still anexperimental feature.
68. Various JS Module Systems + CommonJS ESM Target Advice: CJS/ESM? ESM should be targeted primarily and then if there’s a use case for CJS then go for it as the secondary target.
69. Shall we just compile or bundle the source? Various JS Module Systems CommonJS Target Bundle/ Compile ESM +
70. Compiling: It is a process of transforming the source from one module system to another as per the language specs.
 Tools: Babel PS: Babel is a compiler and not transpiler Bundling: It is a technique most commonly used in today’s “module-based” development where common functionalities can be extracted into a flat bundle at build time. Tools: Webpack/Rollup Various JS Module Systems CommonJS Target Bundle/ Compile ESM +
71. Use Cases? Various JS Module Systems CommonJS Target Bundle/ Compile ESM +
72. Various JS Module Systems CommonJS Target Bundle/ Compile ESM + Component Library: material-ui, blueprint, semantic-ui etc. Core Package: react, react-dom etc. Core Packages Component Library
73. The best approach is publishing different versions of a module for various use cases. 

74. A good example is package.json which contains two entry point versions: “main” and “module” 
 { "name": "ui-kit", "version": "0.0.1", "main": "dist/index.js", "module": "dist/index.mjs", }
75. “main” is the standard field used by node.js ecosystem and therefore it should point to a CJS file.
 “module” field, on the other hand, points to an ES module file.
76. ✅ Checklist Manifesto?
 Thanks Gant for letting me steal this “line” from your slide 3
77. Component Library 1. Consumer Application should be able to include the specific components in your application. import { Button } from 'ui-kit' module: "dist/index.mjs" // ---> The module field in package.json
78. Component Library 1. Consumer Application should be able to include the specific components in your application. import { Button } from 'ui-kit' module: "dist/index.mjs" // ---> The module field in package.json 2. if the consumer application use legacy bundling tools, the author should add support for CJS module system as well. import { Button } from 'ui-kit' main: "dist/index.js" // ---> The main field in package.json
79. Component Library 1. Consumer Application should be able to include the specific components in your application. import { Button } from 'ui-kit' module: "dist/index.mjs" // ---> The module field in package.json 2. if the consumer application use legacy bundling tools, the author should add support for CJS module system as well. import { Button } from 'ui-kit' main: "dist/index.js" // ---> The main field in package.json 3. If the consumer doesn't have ^webpack-4 then no sideEffects benefit. import Button from 'ui-kit/es/Button' import Button from 'ui-kit/cjs/Button'
80. Component Library 1. Consumer Application should be able to include the specific components in your application. import { Button } from 'ui-kit' module: "dist/index.mjs" // ---> The module field in package.json 2. if the consumer application use legacy bundling tools, the author should add support for CJS module system as well. import { Button } from 'ui-kit' main: "dist/index.js" // ---> The main field in package.json 3. If the consumer doesn't have ^webpack-4 then no sideEffects benefit. import Button from 'ui-kit/es/Button' import Button from 'ui-kit/cjs/Button'
 4. Consumer application should be able to directly consume the package i.e 'ui-kit' with <script type="module"> i.e no tree shaking, no side effects in the browser. import Button from "https://unpkg.com/ui-kit/es/Button/index.mjs"
81. Core Packages 1. Consumer Application should be able to include the default and named imports in the application. import api, { get, post } from 'api' module: "dist/index.mjs" // ---> The module field in package.json
82. Core Packages 1. Consumer Application should be able to include the default and named imports in the application. import api, { get, post } from 'api' module: "dist/index.mjs" // ---> The module field in package.json 2. if the consumer application use legacy bundling tools, the author should add support for CJS module system as well. import api, { get, post } from 'api' main: "dist/index.js" // ---> The main field in package.json
83. Core Packages 1. Consumer Application should be able to include the default and named imports in the application. import api, { get, post } from 'api' module: "dist/index.mjs" // ---> The module field in package.json 2. if the consumer application use legacy bundling tools, the author should add support for CJS module system as well. import api, { get, post } from 'api' main: "dist/index.js" // ---> The main field in package.json 3. Consumer application should be able to directly consume the package i.e 'ui-kit' with <script type="module"> i.e no tree shaking, no side effects in the browser. import api, { get, post } from “https://unpkg.com/api/dist/index.mjs” import api, { get, post } from “https://unpkg.com/api/dist/index.js”
84. Component Library ui-kit dist index.js index.mjs cjs Button Text es Button Text
85. Component Library ui-kit dist index.js index.mjs cjs Button Text es Button Text api dist index.js index.mjs Core Packages
86. Various JS Module Systems Core Packages CommonJS Target Bundle/ Compile ESM Component Library + Webpack “sideEffects” Flag
87. Various JS Module Systems Core Packages CommonJS Target Bundle/ Compile ESM + Advice: Bundle/Compile? Component Library: 1. Babelify the source and target CJS and ES. 2. Create “index.mjs” with re-exports. Core Packages: 1. Bundle the source with Rollup and target CJS and ES. Component Library
88. How to Publish? Various JS Module Systems Core Packages Target Bundle/ Compile + CommonJS ESM Publish Component Library
89. Various JS Module Systems Core Packages Target Bundle/ Compile + CommonJS ESM Publish NPM publish It’s as simple as that? > npm version patch -m "Upgrade to %s for reasons” > npm publish Component Library
90. Various JS Module Systems Core Packages Target Bundle/ Compile Component Library + CommonJS ESM Publish NPM publish Hmm, so what’s new in that?
91. Story?
92. Let’s say you’re a team of 5. +7+77
93. 
 Everyone was tired of checking whether the object was null over and over. So one of you implemented “isEmpty” and thought to publish the package as npm module.

94. Everyone runs 
 > npm install --save isEmpty
95. Now someone from team identified that this “isEmpty” doesn’t checks for empty arrays. So they want to make changes to this package. After making changes they publish a minor version of the module to npm. > npm version minor -m "Upgrade to %s for reasons” > npm publish
96. The problem comes if someone wants to use this, they need to update the package version to the latest. “0.30.0” ➡ “0.30.1”
97. What if you were a large team and there was some critical bugfix in one of the package and you want people to upgrade the package version to the latest at any cost? +7+77……+7
98. What if you were a large team and there was some critical bugfix in one of the package and you want people to upgrade the package version to the latest at any cost?
99. Let’s go back one step ⏪:
100. What actually happens when we do “npm install”?
101. What is inside your 
 node_modules?
102. What is inside your 
 node_modules? { "name": "my-package", "files": [ "folder1", "file1" ] }
103. Can we directly copy/paste our package to node_modules?
104. What If we can build the package locally and refer it(symlink) from node_modules?
105. But isn’t that too much of work??

106. ui-kit dist src package.json api dist src package.json my-app build src package.json Repo1 Repo2 Repo3
107. ui-kit dist src package.json api dist src package.json my-app build src package.json Repo1 Repo2 Repo3 ui-kit dist src package.json api dist src package.json my-app build src package.json package.json Repo
108. Left Hand Side VS Right Hand side
109. Left Hand Side It becomes cumbersome if we want to refer(symlink) “ui-kit “ and “api” inside “my-app”.
110. ui-kit dist src package.json api dist src package.json my-app build src package.json Repo1 Repo2 Repo3 ui-kit dist src package.json api dist src package.json my-app build src package.json package.json Repo
111. Right Hand Side It becomes super easy if we want to refer(symlink) “ui-kit “ and “api” inside “my-app”, because they are now within same repo and under one hierarchy
112. ui-kit dist src package.json api dist src package.json my-app build src package.json Repo1 Repo2 Repo3 ui-kit dist src package.json api dist src package.json my-app build src package.json package.json Repo
113. Monorepos? Various JS Module Systems Core Package Target Bundle/ Compile Component Library + CommonJS ESM Publish Monorepos NPM publish
114. But how we will avoid the overhead of symlinking multiple modules?
115. This is exactly what “lerna” is built for!
116. Lerna is a tool that optimizes our workflow around managing npm packages. It is created by awesome people who built babel.
117. You can perform operations like build multiple packages, clean multiple packages, publish multiple packages for all the packages in your monorepo with simple commands.
119. Lerna creates symlinks between the packages that refer each other inside your monorepo. This process is called “bootstrapping”.

120. + Publish Monorepos NPM publish Various JS Module Systems Target CommonJS ESM Core Package Component Library Bundle/ Compile Advice: npm publish/monorepos? Well, If you’re publishing something to be used globally you have to publish it to npm. If you’re building something that is private within your team/org give monorepos a try.
121. Various JS Module Systems + Let’s Reiterate
122. Various JS Module Systems + Let’s Reiterate Target CommonJS ESM
123. Various JS Module Systems + Let’s Reiterate Target CommonJS ESM Core Package Component Library Bundle/ Compile
124. + Publish Monorepos NPM publish Let’s Reiterate Various JS Module Systems Target CommonJS ESM Core Package Component Library Bundle/ Compile
125. /kamleshchandnani/so-you-want-to-build-libraries
126. /kamleshchandnani/so-you-want-to-build-libraries @_kamlesh_
127. Gracias! Thanks for being awesome audience!!