So how can rollups win in the long run?To my mind, there are two ways: one is that a non-rollup sidechain catastrophically fails, and the industry learns a lesson à la Mt. Gox. And catastrophically fail doesn’t just mean “nodes can’t sync.” It means “the money is gone” or “the chain has completely halted.” That’s possible, but probably unlikely.So that leaves us with the other way: rollups have to actually become significantly better than the alternatives. Decentralization virtue signaling is not enough. For this, I personally only see one path forward, which is the promise of cryptography and zero-knowledge proofs.

(Note that ZK rollups don’t suffer from this issue, since their withdrawals are effectively instant.)

Then consider the movement of funds in and out of rollups.For optimistic rollups, when you want to withdraw funds, there is a ~1 week challenge period during which your withdrawal is frozen. This sucks. So to facilitate “fast withdrawals,” market makers will stand ready to move your assets quickly across the boundary—for a fee. The fee they charge you will depend on their inventory and the liquidity of the asset. If you’re moving ETH, this will cost maybe 0.2% or something, but if you’re trying to move a random dog coin, it will likely cost much more, possibly 1% or higher. Some assets may not be possible to fast-withdraw at all if there’s not enough liquidity.

Because of that, it's essential that the bundler doesn't treat the package as an external dependency. You can either modify the external option under server in rollup.config.js or the externals option in webpack.config.js,

Update: I was advised not to import directly from svelte on a reusable publishable store but instead declare svelte as an external.

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

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.

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.

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.

The dedupe option was missing in my project.

If tree-shaking still fails, it's because Rollup thinks that there are side-effects somewhere in your code.

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.

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}`) }

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

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.

If you're using Rollup with rollup-plugin-svelte, this will happen automatically.

/node_modules/

or an Array of module IDs, or regular expressions to match module IDs, that should remain external to the bundle.

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

Rollup will only resolve relative module IDs by default.

Rollup also does something very different compared to the other bundlers. It only tries to achieve one simple goal: Bundle ES modules together and optimise the bundle.

For the past couple of years in particular however, I’ve stopped using Webpack to develop them, opting instead to use Rollup as my primary bundler for apps.

// resolve dependencies from node_modules

// convert CommonJS modules to ES modules

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.

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.

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.

external: ['react']

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:

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.

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.

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.

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

external

// Emit CSS as "files" for other plugins to process emitCss: true,

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

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!

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.

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.