13 Matching Annotations
  1. Sep 2020
    1. To make sure your ES modules are immediately usable by tools that work with CommonJS such as Node.js and webpack, you can use Rollup to compile to UMD or CommonJS format, and then point to that compiled version with the main property in your package.json file.
    2. If your package.json file also has a module field, ES-module-aware tools like Rollup and webpack 2+ will import the ES module version directly.
  2. Dec 2019
    1. Neutrino only babel-compiles first party source (the JSX -> JS transformation is handled by a babel plugin). It does this because even when using the module entry in package.json, it's expected that the provided file (and it's imports) still be JS and not in some other format - ie: the only difference from the content in main should be that it can use modules syntax (that is import and export rather than require etc).

      module version compared to main version:

      only difference from the content in main should be that it can use modules syntax (that is import and export rather than require etc).

      You can see the difference in this example: https://unpkg.com/browse/reactstrap@8.0.1/es/Alert.js ("module": "es/index.js": import) vs. https://unpkg.com/browse/reactstrap@8.0.1/lib/Alert.js ("main": "lib/index.js": require)

    1. Using the browser field in package.json allows a module author to clearly articulate which files are innapropriate for client use and provide alternatives.
    2. The browser field is where the module author can hint to the bundler which elements (other modules or source files) need to be replaced when packaging.