An unknown land of creating libraries

Transcript

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

   View Slide

2. Thanks to our sponsors!
   

   View Slide

3. Introduction!!
   

   View Slide

4. The hardest part of the talk are
   the introductory slides
   

   View Slide

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

   View Slide

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

   View Slide

7. Who am I?
   Not the real question

   
   

   View Slide

8. Real Questions? 

   
   

   View Slide

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

   View Slide

10. What did you use to make the presentation?

    - Keynote
    Which VSCode theme is that?

    - Material
    Which font family is that?

    - Operator mono
    

    View Slide

11. Kamlesh Chandnani
    Namaste $ Alicante %
    

    View Slide

12. Bengaluru,
    India
    

    View Slide

13. @_kamlesh_
    

    View Slide

14. 
    

    View Slide

15. View Slide

16. View Slide

17. Co Organize
    ReactJS ⚛ Meetup Bangalore
    

    View Slide

18. Title?
    

    View Slide

19. An unknown
    land of creating
    libraries
    

    View Slide

20. View Slide

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

    "
    

    View Slide

22. View Slide

23. Let’s Begin
    

    View Slide

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
    

    View Slide

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

    View Slide

26. Why will someone create a
    module?
    

    View Slide

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.
    

    View Slide

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

    View Slide

29. Why JS module
    system?
    Various JS
    Module Systems
    +
    

    View Slide

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

    View Slide

31. In JavaScript, we can’t share code between multiple
    files natively.
    

    View Slide

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

    View Slide

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.
    

    View Slide

34. View Slide

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

    View Slide

36. JavaScript Module Systems solves exactly these
    problems.
    

    View Slide

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

    View Slide

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

    View Slide

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.
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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)
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

48. Various JS
    Module Systems
    + Target
    
    Courtesy $: Addy Osmani
    

    View Slide

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

    View Slide

50. Let’s Code +
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

55. Can you afford it?
    

    View Slide

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

    View Slide

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

    View Slide

58. View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

63. Various JS
    Module Systems
    +
    CommonJS ESM
    Target
    
    There’s more in ESM!
    • ➡ deferred by default.
<br/>• Even if we add the <script type=“module”/><br/>multiple times on the page it gets executed just<br/>once.
<br/>• Global variables is global to that module<br/>(lexical scope) and not to the window scope.
<br/>• You can optimize the delivery of your modules<br/>further by using <link rel=“modulepreload”><br/>PS: This is still anexperimental feature.<br/>

    View Slide

64. 
    
    
    
    
    
    
    
    
    
    
    
    
    

    View Slide

65. Various JS
    Module Systems
    +
    CommonJS ESM
    Target
    
    What Else in ESM?
    • ➡ deferred by default.
<br/>• Even if we add the <script type=“module”/><br/>multiple times on the page it gets executed just<br/>once.
<br/>• Global variables are global to that module<br/>(lexical scope) and not to the window scope.
<br/>• You can optimize the delivery of your modules<br/>further by using <link rel=“modulepreload”><br/>PS: This is still anexperimental feature.<br/>

    View Slide

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

    View Slide

67. Various JS
    Module Systems
    +
    CommonJS ESM
    Target
    
    What Else in ESM?
    • ➡ deferred by default.
<br/>• Even if we add the <script type=“module”/><br/>multiple times on the page it gets executed just<br/>once.
<br/>• Global variables are global to that module<br/>(lexical scope) and not to the window scope.
<br/>• You can optimize the delivery of your modules<br/>further by using <link rel=“modulepreload”><br/>PS: This is still anexperimental feature.<br/>

    View Slide

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.
    

    View Slide

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

    View Slide

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
    +
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    

    View Slide

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

    View Slide

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.
    

    View Slide

76. ✅ Checklist Manifesto?

    Thanks Gant for letting me steal this “line” from your slide 3
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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'
    

    View Slide

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
    i.e no tree shaking, no side effects in the browser.<br/>import Button from "https://unpkg.com/ui-kit/es/Button/index.mjs"<br/>

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    i.e no tree shaking, no side effects in the browser.<br/>import api, { get, post } from “https://unpkg.com/api/dist/index.mjs”<br/>import api, { get, post } from “https://unpkg.com/api/dist/index.js”<br/>

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

91. Story?
    

    View Slide

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

    View Slide

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.

    

    View Slide

94. Everyone runs 

    > npm install --save isEmpty
    

    View Slide

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
    

    View Slide

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”
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

99. Let’s go back one step
    ⏪:
    

    View Slide

100. What actually happens when we do
     “npm install”?
     
     

     View Slide

101. What is inside your 

     node_modules?
     

     View Slide

102. What is inside your 

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

     View Slide

103. Can we directly copy/paste our package to
     node_modules?
     

     View Slide

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

     View Slide

105. But isn’t that too much of work??

     
     

     View Slide

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

     View Slide

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
     

     View Slide

108. Left Hand Side VS Right Hand side
     

     View Slide

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

     View Slide

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
     

     View Slide

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
     

     View Slide

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
     

     View Slide

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

     View Slide

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

     View Slide

115. This is exactly what “lerna” is built
     for!
     

     View Slide

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

     View Slide

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.
     

     View Slide

118. View Slide

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

     

     View Slide

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.
     

     View Slide

121. Various JS
     Module Systems
     + Let’s Reiterate
     

     View Slide

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

     View Slide

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

     View Slide

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

     View Slide

125. /kamleshchandnani/so-you-want-to-build-libraries
     

     View Slide

126. /kamleshchandnani/so-you-want-to-build-libraries
     @_kamlesh_
     

     View Slide

127. Gracias!
     Thanks for being awesome audience!!
     

     View Slide