43 Matching Annotations
  1. Last 7 days
  2. Nov 2020
    1. Update: I was advised not to import directly from svelte on a reusable publishable store but instead declare svelte as an external.
    2. In your case, it sounds like you just want to make svelte external when compiling your components and provide svelte's packages as es modules (straight from npm; look at the .mjs files).
    1. As mentioned in #2937, this is the sort of thing that happens when you have two copies of Svelte's internal scheduler running. If you're importing the compiled version of an external Svelte component into another Svelte component, this is what you end up with. There's a svelte field in package.json that's respected by rollup-plugin-svelte and which is intended to point at the uncompiled Svelte source, so that the external component can be bundled together with the main app, without any duplicated internals.
    1. An Array which instructs the plugin to limit module resolution to those whose names match patterns in the array. Note: Modules not matching any patterns will be marked as external.
    2. An Array of modules names, which instructs the plugin to force resolving for the specified modules to the root node_modules. Helps to prevent bundling the same package multiple times if package is imported from dependencies.
    1. If tree-shaking still fails, it's because Rollup thinks that there are side-effects somewhere in your code.
    1. I think you might want to use resolve just for the umd build, and set svelte/internal as an external dependency for the es build, but I'm not entirely sure.
  3. Oct 2020
    1. To silence circular dependencies warnings for let's say moment library use: // rollup.config.js import path from 'path' const onwarn = warning => { // Silence circular dependency warning for moment package if ( warning.code === 'CIRCULAR_DEPENDENCY' && !warning.importer.indexOf(path.normalize('node_modules/moment/src/lib/')) ) { return } console.warn(`(!) ${warning.message}`) }
    1. If you return an object, then it is possible to resolve an import to a different id while excluding it from the bundle at the same time. This allows you to replace dependencies with external dependencies without the need for the user to mark them as "external" manually via the external option
    2. If you do want to include the module in your bundle, you need to tell Rollup how to find it. In most cases, this is a question of using @rollup/plugin-node-resolve.
  4. Sep 2020
    1. /node_modules/

      This might be better than explicitly listing all external modules...?

    2. or an Array of module IDs, or regular expressions to match module IDs, that should remain external to the bundle.
    3. Resolve imports to module ids (i.e. file names) using the same plugins that Rollup uses, and determine if an import should be external. If null is returned, the import could not be resolved by Rollup or any plugin but was not explicitly marked as external by the use
    4. Rollup will only resolve relative module IDs by default.
    1. using modulesOnly behaves exactly as expected when it warns you that the listed npm libraries do not use the ES6 format and are in fact ignored. This option is meant as a way to determine if you still have commonjs libraries in your dependencies that require special treatment via rollup-plugin-commonjs. Your code will probably not work since the listed dependencies will be missing. You should remove modulesOnly and instead add rollup-plugin-commonjs.
    1. But this is only a halfway decent way to clarify that this is an external dependency, because the only way to resolve a peer dependency warning is to install react from npm—there's no way to notify npm that you resolve the dependency to a browser global. So peer dependencies should be avoided in favor of external declarations. Then Rollup will take care of warning about "unresolved dependencies", even if external declarations can't express a particular version range with which your library is compatible like peer dependencies can.

      Interesting. Didn't realize. From my perspective, I usually do install packages via npm, so wouldn't have known about this problem.

      npm and rollup both try to solve this problem but in different ways that apparently conflict? So if a lib author lists peerDependencies then it can cause problems for those getting lib via browser (CDN)? How come so many libs use it then? How come I've never heard of this problem before?

    2. Now, in the resulting bundle, you'll see that import React from 'react'; remains. This lets the application that consumes this library decide how it would like to resolve this dependency. This will generally be to a browser global, using the the external and globals options, as above; but could be to a local file or even to npm for some reason.
    3. external: ['react']
    4. When you publish this module, you do not want to bundle React, for the reasons described above. (It would be even worse to bundle React in a library, because then its copy would duplicate that loaded by the application!) But the fix is slightly different for a library than an application. In this library's Rollup configuration, we only want to specify external, not globals:
    5. This occurs because, with the configuration above, React is no longer an external dependency: you've directed Rollup to bundle it alongside your application's local JavaScript. But there are critical differences between your application's JS and React's.
    6. If you've followed React's guide, you've installed react from npm. You can teach Rollup how to find this package within your project's node_modules directory using the rollup-plugin-node-resolve plugin. Since React exports a CommonJS module, you'll also need to convert that into an ES6 module using the rollup-plugin-commonjs plugin.
    7. There are two ways of handling this with Rollup, as described by the troubleshooting link from the warning. Unfortunately, both Rollup and React recommend the wrong one.
    8. Rollup is a tool that lets you write your application using ES6 modules, even though you can't publish those modules directly to your users, because native support is only just starting to land in browsers. Rollup compiles your modules into a format that all browsers _do_ understand—a single script file—by, essentially, concatenating files together (while reordering and renaming declarations to preserve scope).
    1. we've learned why you might want to use external but not globals: libraries. We've started to factor some of our client-side JS as libraries to share between projects. These libraries import $ from 'jquery'. However they don't want to presume how that import might be "fulfilled". In most projects it's fulfilled from a global i.e. a script loaded from a CDN. However in one project it's fulfilled from a local copy of jQuery for reasons I won't get into. So when these libraries bundle themselves for distribution, as ES6 modules, they mark 'jquery' as an external and not as a global. This leaves the import statements in the bundle. (Warning: Don't bundle as an IIFE or UMD, or Rollup will guess at fulfilling the import from a global, as @Rich-Harris mentions above.)
    1. This is a demonstration of building a custom D3 4.0 bundle using ES2015 modules and Rollup. Custom bundles can be optimized to contain only the code you need. This example exposes just three fields on the d3 object: d3.event, d3.select and d3.selectAll. The minified and gzipped bundle is only 3,691 bytes, a savings of 93% over the default build!
    1. It looks like the issue stems from having "svelte" as a dependency instead of a devDependencies in package.json within the sapper project. This causes import 'svelte' to load the rollup excluded npm package's set_current_component instead of from within the sapper generated server.js.
    1. Also, Rollup, which I use in the article as a bundler is pretty slow. Why? Because it needs to re-compile the whole shebang every time you change a file. It produces very small and efficient bundles though.