An unknown land of creating libraries

Slide 1

Slide 1 text

September 2018 Title on the way Sit back and relax Who am I? "

Slide 2

Slide 2 text

Thanks to our sponsors!

Slide 3

Slide 3 text

Introduction!!

Slide 4

Slide 4 text

The hardest part of the talk are the introductory slides

Slide 5

Slide 5 text

Then, Title of the talk - Author Name Slide 1: Talk Begins Slide 2:

Slide 6

Slide 6 text

Now, Author Name Slide 1: Title of the talk Slide 2: Slide 3: : Talk Begins Slide 8: : :

Slide 7

Slide 7 text

Who am I? Not the real question 

Slide 8

Slide 8 text

Real Questions?  

Slide 9

Slide 9 text

What did you use to make the presentation? Which VSCode theme is that? Which font family is that?

Slide 10

Slide 10 text

What did you use to make the presentation?  - Keynote Which VSCode theme is that?  - Material Which font family is that?  - Operator mono

Slide 11

Slide 11 text

Kamlesh Chandnani Namaste $ Alicante %

Slide 12

Slide 12 text

Bengaluru, India

Slide 13

Slide 13 text

@_kamlesh_

Slide 14

Slide 14 text

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Co Organize ReactJS ⚛ Meetup Bangalore

Slide 18

Slide 18 text

Title?

Slide 19

Slide 19 text

An unknown land of creating libraries

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

TL;DR: I don’t know what I’ll be talking   "

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Let’s Begin

Slide 24

Slide 24 text

What is a package? A package is a namespace that organises set of related ﬁles/modules that are responsible of doing some task. In node.js every package has a package.json which has the metadata about that package

Slide 25

Slide 25 text

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');

Slide 26

Slide 26 text

Why will someone create a module?

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

So now since we know the “Why” part of it let’s address the “How” part of it

Slide 29

Slide 29 text

Why JS module system? Various JS Module Systems +

Slide 30

Slide 30 text

// file1.js const makeMessage = (message) => { return `Message: ${message}`; } // file2.js const showMessage = () => { const message = makeMessage('Calling makeMessage’) // makeMessage is undefined console.log(message); }

Slide 31

Slide 31 text

In JavaScript, we can’t share code between multiple ﬁles natively.

Slide 32

Slide 32 text

// file2.js const makeMessage = (message) => { return `Message: ${message}`; } const showMessage = () => { const message = makeMessage('Calling makeMessage') console.log(message); }

Slide 33

Slide 33 text

This was just a small piece of code, but imagine if you have big massive application and you’re writing everything in one ﬁle.

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Issues 1. Messy Code 2. Fucked up Dependency management. 3. Refactoring becomes painful.

Slide 36

Slide 36 text

JavaScript Module Systems solves exactly these problems.

Slide 37

Slide 37 text

What are the different types of JS module systems? Various JS Module Systems +

Slide 38

Slide 38 text

1. CommonJS 2. AMD: Async Module Deﬁnition 3. UMD: Universal Module Deﬁnition 4. ECMAScript Harmony (ES6) Various JS Module Systems +

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

AMD: Async Module Deﬁnition 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

Slide 43

Slide 43 text

UMD: Universal Module Deﬁnition 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)

Slide 44

Slide 44 text

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.

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

All of these module systems have one thing in common: they allow you to import and export stuff Various JS Module Systems +

Slide 47

Slide 47 text

What module system to target? Various JS Module Systems + Target

Slide 48

Slide 48 text

Various JS Module Systems + Target Courtesy $: Addy Osmani

Slide 49

Slide 49 text

Various JS Module Systems + Target 500 million internet users in India ~ 52.4% users are on 3G and slower networks

Slide 50

Slide 50 text

Let’s Code +

Slide 51

Slide 51 text

export default class ecmascript { showMessage = () => { console.log('Welcome to the world of ES'); }; } ES RAW

Slide 52

Slide 52 text

export default class ecmascript { constructor() { this.showMessage = () => { console.log('Welcome to the world of ES'); }; } } ES (“modules”: false)

Slide 53

Slide 53 text

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”)

Slide 54

Slide 54 text

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”)

Slide 55

Slide 55 text

Can you afford it?

Slide 56

Slide 56 text

Considering the fact that you’re building your code as ES target but still what about unused code?

Slide 57

Slide 57 text

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”.

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

Various JS Module Systems + Target “Ship whatever is needed”

Slide 62

Slide 62 text

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? ❌ ✅

Slide 63

Slide 63 text

Various JS Module Systems + CommonJS ESM Target There’s more in ESM! • ➡ 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.

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Various JS Module Systems + CommonJS ESM Target What Else in ESM? • ➡ 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.

Slide 66

Slide 66 text

const testModule = "This is a module" console.log({ testModule }) // testModule is undefined Scope

Slide 67

Slide 67 text

Slide 68

Slide 68 text

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.

Slide 69

Slide 69 text

Shall we just compile or bundle the source? Various JS Module Systems CommonJS Target Bundle/ Compile ESM +

Slide 70

Slide 70 text

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 ﬂat bundle at build time. Tools: Webpack/Rollup Various JS Module Systems CommonJS Target Bundle/ Compile ESM +

Slide 71

Slide 71 text

Use Cases? Various JS Module Systems CommonJS Target Bundle/ Compile ESM +

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

The best approach is publishing different versions of a module for various use cases.  

Slide 74

Slide 74 text

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", }

Slide 75

Slide 75 text

“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.

Slide 76

Slide 76 text

✅ Checklist Manifesto?  Thanks Gant for letting me steal this “line” from your slide 3

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Component Library 1. Consumer Application should be able to include the speciﬁc 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 beneﬁt. import Button from 'ui-kit/es/Button' import Button from 'ui-kit/cjs/Button'

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

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 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”

Slide 84

Slide 84 text

Component Library ui-kit dist index.js index.mjs cjs Button Text es Button Text

Slide 85

Slide 85 text

Component Library ui-kit dist index.js index.mjs cjs Button Text es Button Text api dist index.js index.mjs Core Packages

Slide 86

Slide 86 text

Various JS Module Systems Core Packages CommonJS Target Bundle/ Compile ESM Component Library + Webpack “sideEffects” Flag

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

How to Publish? Various JS Module Systems Core Packages Target Bundle/ Compile + CommonJS ESM Publish Component Library

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

Various JS Module Systems Core Packages Target Bundle/ Compile Component Library + CommonJS ESM Publish NPM publish Hmm, so what’s new in that?

Slide 91

Slide 91 text

Story?

Slide 92

Slide 92 text

Let’s say you’re a team of 5. +7+77

Slide 93

Slide 93 text

  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. 

Slide 94

Slide 94 text

Everyone runs   > npm install --save isEmpty

Slide 95

Slide 95 text

Now someone from team identiﬁed 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

Slide 96

Slide 96 text

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”

Slide 97

Slide 97 text

What if you were a large team and there was some critical bugﬁx in one of the package and you want people to upgrade the package version to the latest at any cost? +7+77……+7

Slide 98

Slide 98 text

What if you were a large team and there was some critical bugﬁx in one of the package and you want people to upgrade the package version to the latest at any cost?

Slide 99

Slide 99 text

Let’s go back one step ⏪:

Slide 100

Slide 100 text

What actually happens when we do “npm install”?

Slide 101

Slide 101 text

What is inside your   node_modules?

Slide 102

Slide 102 text

What is inside your   node_modules? { "name": "my-package", "files": [ "folder1", "file1" ] }

Slide 103

Slide 103 text

Can we directly copy/paste our package to node_modules?

Slide 104

Slide 104 text

What If we can build the package locally and refer it(symlink) from node_modules?

Slide 105

Slide 105 text

But isn’t that too much of work?? 

Slide 106

Slide 106 text

ui-kit dist src package.json api dist src package.json my-app build src package.json Repo1 Repo2 Repo3

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

Left Hand Side VS Right Hand side

Slide 109

Slide 109 text

Left Hand Side It becomes cumbersome if we want to refer(symlink) “ui-kit “ and “api” inside “my-app”.

Slide 110

Slide 110 text

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

Slide 113

Slide 113 text

Monorepos? Various JS Module Systems Core Package Target Bundle/ Compile Component Library + CommonJS ESM Publish Monorepos NPM publish

Slide 114

Slide 114 text

But how we will avoid the overhead of symlinking multiple modules?

Slide 115

Slide 115 text

This is exactly what “lerna” is built for!

Slide 116

Slide 116 text

Lerna is a tool that optimizes our workﬂow around managing npm packages. It is created by awesome people who built babel.

Slide 117

Slide 117 text

You can perform operations like build multiple packages, clean multiple packages, publish multiple packages for all the packages in your monorepo with simple commands.

Slide 118

Slide 118 text

No content

Slide 119

Slide 119 text

Lerna creates symlinks between the packages that refer each other inside your monorepo. This process is called “bootstrapping”. 

Slide 120

Slide 120 text

+ 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.

Slide 121

Slide 121 text

Various JS Module Systems + Let’s Reiterate

Slide 122

Slide 122 text

Various JS Module Systems + Let’s Reiterate Target CommonJS ESM

Slide 123

Slide 123 text

Various JS Module Systems + Let’s Reiterate Target CommonJS ESM Core Package Component Library Bundle/ Compile

Slide 124

Slide 124 text

+ Publish Monorepos NPM publish Let’s Reiterate Various JS Module Systems Target CommonJS ESM Core Package Component Library Bundle/ Compile