rollup / plugins

🍣 The one-stop shop for official Rollup plugins

Rollup Plugins

🍣 The one-stop shop for official Rollup plugins

This repository houses plugins that Rollup considers critical to every day use of Rollup, plugins which the organization has adopted maintenance of, and plugins that the project recommends to its users.

Plugins Found Here

alias	Define and resolve aliases for bundle dependencies
auto-install	Automatically install dependencies that are imported by a bundle
babel	Compile your files with Babel
beep	System beeps on errors and warnings
buble	Compile ES2015 with buble
commonjs	Convert CommonJS modules to ES6
data-uri	Import modules from Data URIs
dsv	Convert .csv and .tsv files into JavaScript modules with d3-dsv
dynamic-import-vars	Resolving dynamic imports that contain variables.
eslint	Verify entry point and all imported files with ESLint
esm-shim	Replace cjs syntax for esm output bundles
graphql	Convert .gql/.graphql files to ES6 modules
html	Create HTML files to serve Rollup bundles
image	Import JPG, PNG, GIF, SVG, and WebP files
inject	Scan modules for global variables and injects import statements where necessary
json	Convert .json files to ES6 modules
legacy	Add export declarations to legacy non-module scripts
multi-entry	Use multiple entry points for a bundle
node-resolve	Locate and bundle third-party dependencies in node_modules
replace	Replace strings in files while bundling
run	Run your bundles in Node once they're built
strip	Remove debugger statements and functions like assert.equal and console.log from your code
sucrase	Compile TypeScript, Flow, JSX, etc with Sucrase
swc	Transpile TypeScript/JavaScript with the speedy-web-compiler
terser	Generate a minified output bundle with terser
typescript	Integration between Rollup and Typescript
url	Import files as data-URIs or ES Modules
virtual	Load virtual modules from memory
wasm	Import WebAssembly code with Rollup
yaml	Convert YAML files to ES6 modules

Other Packages Found Here

pluginutils	A set of utility functions commonly used by Rollup plugins

Contributing

This repository is a monorepo which leverages pnpm for dependency management.

To begin, please install pnpm:

$ npm install pnpm -g

Working with Plugin Packages

All plugin packages are kept in the /packages directory.

Adding dependencies:

$ pnpm --filter ./packages/<name> add <package>

Where <package> is the name of the NPM package you wish to add for a plugin package, and <name> is the proper name of the plugin. e.g. @rollup/plugin-beep.

Publishing:

$ pnpm publish <name> [flags]

Where <name> is the portion of the plugin package name following @rollup/plugin-. (e.g. beep)

The publish script performs the following actions:

• Gathers commits from the last release tag
• Determines the next appropriate version bump (major, minor, or patch)
• Updates package.json
• Generates a new ChangeLog entry
• Updates CHANGELOG.md for the target plugin
• Commits package.json and CHANGELOG.md, with a commit message is in the form chore(release): <name>-v<version>
• Publishes to NPM
• Tags the release in the form <name>-v<version> (e.g. beep-v0.1.0)
• Pushes the commit and tag to Github

Flags

The following flags are available to modify the publish process:

• --dry tells the script to perform a dry-run, skipping any file modifications, NPM, or Git Actions. Results from version determination and new ChangeLog additions are displayed.
• --major, --minor, --patch can be used to force a particular type of semver bump.
• --no-push will instruct the script not to push changes and tags to Git.
• --no-tag will instruct the script not to tag the release.

Running Tests:

To run tests on all packages which have changes:

$ pnpm test

To run tests on a specific package:

$ pnpm --filter ./packages/<name> test

Linting:

To lint all packages which have changes:

$ pnpm lint

To lint a specific package:

$ pnpm --filter ./packages/<name> lint

Note: Scripts in the repository will run the root test and lint script on those packages which have changes. This is also how the CI pipelines function. To run either on a package outside of that pipeline, use pnpm <script> @rollup/plugin-<name>.

Adding Plugins

While we don't have an official procedure for adding third-party plugins to this repository, we are absolutely open to the idea. If you'd like to speak about your project being a part of this repo, please reach out to @RollupJS on Twitter.

Meta

CONTRIBUTING

LICENSE (MIT)

plugins's Issues

(plugin-alias) Can't get preact/compact to replace react imports

I'm trying to add graphiql to my sapper (svelte + ssr) application by dynamically importing preact and graphiql but i can't get preact/compat working so i can use react components in a preact project.

I use the rollup config provided by sapper and added alias to it:

  // ...
  alias({
    entries: [
      { find: "react", replacement: path.resolve(__dirname, "node_modules/preact/compat/dist/compat.js") },
      { find: "react-dom", replacement: path.resolve(__dirname, "node_modules/preact/compat/dist/compat.js") },
    ]
  }),
  resolve({
    browser: true,
    dedupe,
  }),
  commonjs(),
  // ...

After adding that sapper starts without any errors, but when opening the web server i get a wired error:

preact.js:formatted:1 Uncaught (in promise) TypeError: Cannot convert object to primitive value
    at j (preact.module.js:formatted:1)
    at T (preact.module.js:formatted:1)
    at preact.module.js:formatted:1
    at b (preact.module.js:formatted:1)
    at b (preact.module.js:formatted:1)
    at _ (preact.module.js:formatted:1)
    at T (preact.module.js:formatted:1)
    at E (preact.module.js:formatted:1)
    at show (graphiql.js:7)

My svelte code (to test the react to preact/compat alias i'm using react-greeting):

<script>
  import { onMount } from 'svelte';
  let rootEl;

  onMount(async() => {
    const { h, Component, render, createElement } = await import('preact');
    const Greeting = await import('react-greeting');

    render(createElement(Greeting, {}, null), rootEl);
  });
</script>

<div bind:this={rootEl} />

Also placing this code in a js file and dynamically importing that or directly importing and dynamically calling the code in there gives the same result.

property.name.kind access when property.name is undefined

• Rollup Plugin Name: @rollup/plugin-typescript
• Rollup Plugin Version: 2.0.1
• Rollup Version: 1.27.13
• Operating System (or Browser): windows 10
• Node Version: v8.16.2

How Do We Reproduce?

rollup-typescript-problem.zip

1. unpack rollup-typescript-problem.zip
2. npm i
3. .\node_modules\.bin\rollup --config

Expected Behavior

compile without errors

Actual Behavior

>.\node_modules\.bin\rollup --config

index.ts → ....
[!] (plugin typescript) TypeError: Cannot read property 'kind' of undefined
index.ts
TypeError: Cannot read property 'kind' of undefined
    at visitObjectLiteralExpression (C:\test\node_modules\typescript\lib\typescript.js:80338:35)
    at visitJavaScript (C:\test\node_modules\typescript\lib\typescript.js:78758:28)
    at visitor (C:\test\node_modules\typescript\lib\typescript.js:78701:24)
    at Object.visitNode (C:\test\node_modules\typescript\lib\typescript.js:70936:23)
    at flattenBindingOrAssignmentElement (C:\test\node_modules\typescript\lib\typescript.js:73016:34)
    at flattenObjectBindingOrAssignmentPattern (C:\test\node_modules\typescript\lib\typescript.js:73078:21)
    at flattenBindingOrAssignmentElement (C:\test\node_modules\typescript\lib\typescript.js:73028:13)
    at Object.flattenDestructuringBinding (C:\test\node_modules\typescript\lib\typescript.js:72962:9)
    at visitVariableDeclaration (C:\test\node_modules\typescript\lib\typescript.js:80117:30)
    at Object.flatMap (C:\test\node_modules\typescript\lib\typescript.js:607:25)

Comment

If this isn't a bug in using typescript, it might be a bug in typescript itself, but I've only encountered it while using this rollup plugin. Please feel free to pass the buck to the TS team if
appropriate;-)

workaround/possible fix: in typescript.js, line 80338, protect property.name.kind by checking for property.name first.

Monorepo: Seamless Package Publishing

• Rollup Plugin Name: n/a
• Rollup Plugin Version: n/a

Feature Use Case

To publish a module in the monorepo at the moment, we have to manually perform the following tasks:

• merge relevant pull requests (this step won't go away)
• change the package version appropriately
• update the changelog manually from commits
• run pnpm run publish -- <name>

Feature Proposal

I'd like to work some automagic into the publish script process. Namely:

• add a --version flag, which would accept the same patch|minor|major values that npm does
• parse the commit log to pull relevant commits for the target plugin name, and automatically update the CHANGELOG for a plugin. This would require a standard commit format. e.g. fix(beep), docs(beep), feat(beep), etc. And I know that's something that @lukastaegert is not a fan of, so it's worth discussing here.
• finally, actually publish the plugin

Alternatively, we could let the changelog decide what type of a semver update the publish should be, if we all agree to use a commit format that can be parsed as such. fix|docs|chore all fall into patch, feat is minor, and we'd have to have a means of tagging something a breaking change that would necessitate a major, or we can use a flag like --breaking to specify a major with breaking changes, or --major for a major version without breaking changes.

There's also the question of how to annotate the CHANGELOG for a plugin with breaking changes.

/cc @rollup/plugin-maintainers

Browser field regression

rollup/rollup-plugin-node-resolve#127 introduced changes that broke our particular use of pkg.browser. We have packages that have a single import when used from node, but separate imports when used in browser modules.

For instance, let's say we have a utils module:

utils/
  package.json
  node.index.js
  dist/
    browser/
      string/
        index.js
  src/
    string/
      index.js

// package.json
{
  "name": "utils",
  "main": "node.index.js",
  "browser": {
    "string/index.js": "dist/browser/string/index.js"
  }
}

// node.index.js
exports.string = require('./src/string');

Which we use in two ways:

// from node (no bundler)
const {string: {interpolate}} = require('utils');

// from browser target (with rollup-plugin-node-resolve, {browser: true})
import {interpolate} from 'utils/string';

Because string/index.js isn't a real file, resolve fails to find it, and resolveId gives a falsy resolved. In 3.0.0, this was different, as it took the id utils/string and tried to resolve it with a few different paths, including utils/string/index.js. It looked that key up in the browser object, and got dist/browser/string/index.js, which exited, so all was well.

I realize this may not be a use-case you want to support (I'm curious to know what tweaks you'd make to the structure of the utils package to achieve the import goals), but it was supported in 3.0.0. To me, this makes rollup/rollup-plugin-node-resolve#127 a major rev, and 3.0.1 a backwards-incompatible change.

Not trying to call anybody out on this - it's a super weird use-case; just pointing out that the use-case exists, and wondering if it's something we want to support vs a use-case that shouldn't be supported in the first place.

@rollup/plugin-html was not found in npm registry

• Rollup Plugin Name: @rollup/plugin-html
• Rollup Plugin Version:

Documentation Is:

• Missing
• Needed
• Confusing
• Not Sure?

Please Explain in Detail...

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@rollup%2fplugin-html - Not found
npm ERR! 404
npm ERR! 404  '@rollup/plugin-html@latest' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

Your Proposal for Changes

Error: Could not load [object Object]

• Node-Resolve Plugin Version: 5.2.0
• Rollup Version: 1.27.2
• Operating System (or Browser): Windows 10
• Node Version: 12.13.0

How Do We Reproduce?

Reproduction steps are outlined in this reduced test case repo:

https://github.com/Dan503/BUG-rollup-plugin-node-resolve/tree/master

Note this part of gulpfile.js in particular:

const rollupJS = (inputFile, options) => {
	return () => {
		return (
			rollup({
				input: options.basePath + inputFile,
				format: options.format,
				sourcemap: options.sourcemap,
				plugins: [resolve()], // <<-- This is the line that calls rollup-plugin-node-resolve
			})
				.pipe(source(inputFile, options.basePath))
				.pipe(buffer())
				.pipe(sourcemaps.init({ loadMaps: true }))
				.pipe(sourcemaps.write('.'))
				.pipe(gulp.dest(options.distPath))
		)
	}
}

Expected Behavior

It should not error

Actual Behavior

It throws this error when trying to run the code:

Error: Could not load [object Object]: The "path" argument must be one of type string, Buffer, or URL. Received type object
    at C:\xxx\Bug-recreations\rollup-plugin-node-resolve\node_modules\rollup-stream\node_modules\rollup\dist\rollup.js:9715:11
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

Update docs; address possible symlink deficiencies

• Rollup Plugin Name: node-resolve
• Rollup Plugin Version: 6.0.0

Documentation Is:

• Missing
• Needed
• Confusing
• Not Sure?

Please Explain in Detail...

Mostly a port of an old issue, described here: rollup/rollup-plugin-node-resolve#244 (comment).

Your Proposal for Changes

Please see referenced thread.

mistake in plugin-virtual readme

• Rollup Plugin Name: virtual
• Rollup Plugin Version: *
• Rollup Version: *
• Operating System (or Browser): *
• Node Version: *

How Do We Reproduce?

in README

Expected Behavior

at https://github.com/rollup/plugins/tree/master/packages/virtual#install install command should be right

Actual Behavior

presently it is command to install yaml plugin instead

jsx: `preserve` does not compile

Hi,
I'm trying to compile .tsx preserving the JSX output but have a problem whenever using jsx: 'preserve'. It only works when using jsx: 'react' but it's not the output I'm looking for.
Any ideas or workarounds or am I missing something?

Thanks

rollup.config.json

import typescript from 'rollup-plugin-typescript';

export default {
	output: {name: 'foo', format: 'iife'},
	plugins: [
		typescript({
			jsx: 'preserve',
			target: 'esnext',
			lib: ['es5', 'es6', 'dom']
		})
	]
};

main.tsx

export default <span>Yo!</span>

rollup -c -- main.tsx

[!] Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)
lib/scripts/main.tsx (1:15)
1: export default <span>Yo!</span>
                  ^
Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)

typescript plugin still references rollup-pluginutils

• Rollup Plugin Name: typescript
• Rollup Plugin Version: 2.0.0
• Rollup Version: 1.27.8
• Operating System (or Browser): macOS
• Node Version: 12.13.1

How Do We Reproduce?

• Install the typescript plugin npm i --save-dev @rollup/plugin-typescript typescript tslib
• Add it to rollup.config.js
• Run rollup -c

Expected Behavior

It should work ;)

Actual Behavior

> rollup -cw

[!] Error: Cannot find module 'rollup-pluginutils'
Require stack:
- /Users/lukas/Documents/Bachmann/atscm/transformer-help/node_modules/@rollup/plugin-typescript/dist/index.js
- /Users/lukas/Documents/Bachmann/atscm/transformer-help/rollup.config.js
- /Users/lukas/Documents/Bachmann/atscm/transformer-help/node_modules/rollup/dist/bin/rollup
Error: Cannot find module 'rollup-pluginutils'

Reason

The problem is, that index.js still imports 'rollup-pluginutils' instead of '@rollup/pluginutils'.

Workaround

Install rollup-pluginutils: npm i --save-dev rollup-pluginutils

Are you on this one or should I create a PR?

eslint fails with "Unable to resolve path to module '@rollup/plugin-json'"

• Rollup Plugin Name: rollup-json
• Rollup Plugin Version: 4.0.0
• Rollup Version: 1.27.13
• Operating System (or Browser): macOS 10.13
• Node Version: v12.13.1

How Do We Reproduce?

In my rollup.config.js I changed import json from 'rollup-plugin-json' to import json from '@rollup/plugin-json'; and of course, installed @rollup/plugin-json.

Expected Behavior

No eslint errors

Actual Behavior

7:18 error Unable to resolve path to module '@rollup/plugin-json' import/no-unresolved
✖ 1 problem (1 error, 0 warnings)

Suppressing the error seems to do the trick so it is actually correctly resolved.

Resolve breaks certain css files

This looks like an issue with the interaction of resolve and postcss. Certain imported css files are included without an issue, but others disappear without a trace. Note that this happens only when using resolve (see details), so I have submitted it here. I hope that this is the right place for it!

The issue appears when trying to import vuetify's css with resolve and postcss.

• Node-Resolve Plugin Version: 5.2.0
• Rollup Version: 1.20.2
• Operating System (or Browser): archlinux
• Node Version: 12.9.1

How Do We Reproduce?

When trying to import vuetify css with resolve, it simply is not included, as if the import didn't exist

// test.js
import 'vuetify/dist/vuetify.css';

npm i rollup rollup-plugin-node-resolve rollup-plugin-postcss vuetify codemirror

// rollup.config.js
import resolve from "rollup-plugin-node-resolve"
import postcss from "rollup-plugin-postcss"

export default {
  input: "test.js",
  output: {
    file: "test.mjs",
    format: "es"
  },
  plugins: [resolve(),postcss()]
}

Running rollup with rollup -c

Expected Behavior

Importing certain files with resolve works fine

// test.js
import 'codemirror/lib/codemirror.css';

Importing the problematic file directly (without resolve) also works without issue

cp node_modules/vuetify/dist/vuetify.css ./vuetify.css

// test.js
import "./vuetify.css"

Trying to import a file that does not exist gives the expected error

import "doesnotexist.css"; // as expected, fails with "Unresolved dependencies" error

Actual Behavior

// test.js
import 'vuetify/dist/vuetify.css';

An empty bundle is generated, without any error.

Don't add file extensions automatically

This issue was transferred from rollup-plugin-alias, which lacked an issue template

---

Reviewing the various PRs for rollup/rollup-plugin-alias#11, I was struck by how much extra work is created for the sake of allowing users to do this...

alias({
  foo: 'bar'
})

...when they mean this:

alias({
  foo: 'bar.js'
})

In my view there's no good reason to support that. Extension-less imports is a bad habit encouraged by Node's ill-conceived module resolution algorithm. Being explicit and obvious (rather than relying on scattered bits of magic) makes life easier for whichever developer inherits a project, and it would allow us to remove a lot of moving parts (including the resolve option).

Breaking, obviously, so would have to be a version 2. Thoughts?

entry-point [!] Error: ENOENT: no such file or directory

• Rollup Plugin Name: @rollup/plugin-multi-entry
• Rollup Plugin Version: 3.0.0
• Rollup Version: 1.27.10
• Operating System (or Browser): windows
• Node Version: 10.15.3

is anyone who could tell me how to fix it ?

plugin-alias: Resolve isn't applied on all imports

Hi !

So, I can't figure out if it's a normal behavior or not but like I said in the title, not all paths are resolved by the @rollup/plugin-alias extension.

• Rollup Plugin Name: alias
• Rollup Plugin Version: 2.2.0
• Rollup Version: 1.27.0
• Operating System (or Browser): Mac OS Catalina, Firefox 70
• Node Version: 13.1

How Do We Reproduce?

Here's an example:

My configuration of the alias plugin in rollup.config.js:

...
alias({
    entries: {
        'src': `${__dirname}/src`
    },
    resolve: [
        '.js',
        '.svelte',
        '/index.js',
        '/index.svelte',
        ''
    ],
}),
...

We imagine that there is a svelte component called Button.svelte in src/components.

So this works:

src/pages/Home.svelte:

...
import Button from 'src/components/Button';
...

Please note that here the component is imported via the alias src created before in the plugin configuration.

Source code

Expected Behavior

So I expect this to work (src/pages/Home.svelte):

...
import Button from '../components/Button';
...

Actual Behavior

Yet, it doesn't.

The error will be:

[!] Error: Could not resolve '../components/Button' from src/pages/Home.svelte
Error: Could not resolve '../components/Button' from src/pages/Home.svelte
    at error (/Users/k/Documents/Code/Svelte/svind/node_modules/rollup/dist/rollup.js
:5351:30)
    at ModuleLoader.handleMissingImports (/Users/k/Documents/Code/Svelte/svind/node_m
odules/rollup/dist/rollup.js:12192:17)
    at ModuleLoader.<anonymous> (/Users/k/Documents/Code/Svelte/svind/node_modules/ro
llup/dist/rollup.js:12083:30)
    at Generator.next (<anonymous>)
    at fulfilled (/Users/k/Documents/Code/Svelte/svind/node_modules/rollup/dist/rollu
p.js:41:28)

So I'm forced to do:

src/pages/Home.svelte:

...
import Button from '../components/Button.svelte';
...

And it doesn't seem logical to me.

I don't know if I have to add I rule to the alias function in rollup.config.js or not ? I tried everything and if it cannot work, I think that it would be a nice feature to have, especially when you have components that have components.

@rollup/plugin-replace has larger install size than rollup-plugin-replace

• Rollup Plugin Name: @rollup/plugin-replace
• Rollup Plugin Version: 2.2.0
• Rollup Version: 1.26.3
• Operating System (or Browser): MacOS
• Node Version: v10.17.0

How Do We Reproduce?

Hello! 👋 I noticed (for reasons I don't quite follow) that the install size for the replace plugin has seemingly ballooned after getting moved into the monorepo. Before the move it was a cool 2.64 MB.

But now it's much larger, at 44.4 MB.

Is this a miscalcuation or did someone happen to change during the transition?

Expected Behavior

The install size should be nearly identical post-move to the @rollup/plugin-replace.

Actual Behavior

It is not.

--

Thank you!

Error: [type] is not exported by [file]

(This issue was transferred from rollup-plugin-typescript and had no issue template)

This code:

import { Type1, Type2 } from './file.ts';

export {
	Type2
}

export const fn1: Type1 = () => {
	// ...
}

Throws this error in the console:

[!] Error: 'Type2' is not exported by src/file.ts

Is there any workaround or fix for this?

commonjs + inject

• Rollup Plugin Name: commonjs, inject
• Rollup Plugin Version: @rollup/[email protected], [email protected]
• Rollup Version: v1.27.13
• Operating System (or Browser): Linux
• Node Version: 10.17.0

How Do We Reproduce?

https://github.com/drzraf/rollup-issue-92

Expected Behavior

Injection works with commonjs

Actual Behavior

Browser throws ReferenceError: module is not defined

Make error output nice

Hey,

errors look bad compared to rollup or babel cli. Take a look:

1. Rollup error without babel plugin. Very minimal and clean:

2. Babel cli error. Not minimal, a little messy:

3. Rollup error with babel plugin. Huge, duplicated code frame, the message of the error is so far away that my eyes have to search for it to read (due to included full file path):

Is it somehow possible to make the error output better? It's really hard to read this errors.

cannot deduplicate custom module dirs

Rollup Plugin Name: @rollup/plugin-node-resolve
Rollup Plugin Version: 6.0.0
Rollup Version: 1.27.13
Operating System (or Browser): macOS Sierra
Node Version: 10.16.0

How Do We Reproduce?

Use customResolveOptions to set a custom module directory, and enable dedupe for modules.

Expected Behavior

Modules are deduplicated.

Actual Behavior

Modules are not deduplicated. This is because the node_modules directory is hardcoded.

Add only option to external

• Rollup Plugin Name: node-resolve
• Rollup Plugin Version: 6.0.0

Feature Use Case

Transfer from rollup/rollup-plugin-node-resolve#245

Feature Proposal

Transfer from rollup/rollup-plugin-node-resolve#245

The Result of `unwrapExports` is Never Assigned

This issue was transferred from rollup/rollup-plugin-commonjs, which had no issue templates

I'm trying to bundle styled-jsx with my React comment and getting errors resulting from the unwrapExports function being called but never assigned. Here is the abbreviated output:

/* ... */

function createCommonjsModule(fn, module) {
    return module = {
        exports: {}
    }, fn(module, module.exports), module.exports;
}

/* ... */

var style = createCommonjsModule(function(module, exports) {

    Object.defineProperty(exports, "__esModule", {
        value: true
    });
    exports.flush = flush;
    exports.default = void 0;
    
    /* ... */
    
    var JSXStyle =
        /*#__PURE__*/
        function(_Component) {/* ... */}(React.Component);

    exports.default = JSXStyle;

    function flush() {/* ... */}
});

unwrapExports(style);
var style_1 = style.flush;

var style$1 = style;

As you can see, unwrapExports(style); is called, but never assigned to style$1. This results in errors when any methods of style$1 are used since its value is module.exports (via createCommonjsModule) instead of module.exports.default.

If I alter the last line to be the following, everything works as expected:

var style$1 = unwrapExports(style);

Am I possibly misconfiguring the plugin? Any pointers will be much appreciated.

define entries by function

This issue was transferred from rollup-plugin-alias, which lacked an issue template

---

future idea

      alias({
        entries: [
          (id) => `replaced_${id}`
        ]
      })

expect

same work

      alias({
        entries: [
          { find: /^.*$/, replacement: $0 }
        ]
      })

base64 svg may end up in bigger size

In this example of 2 data strings the base64 is bigger.

http://codepen.io/anon/pen/ZONxYR

Would it may make sense to not base64 svg?

Plugin Migration

Below is the big-ass list of plugins that need migrating into this repo:

Done

• rollup-plugin-alias
• plugin-auto-install
• rollup-plugin-buble
• rollup-plugin-commonjs
• rollup-plugin-dsv
• rollup-plugin-image
• rollup-plugin-inject
• rollup-plugin-json
• rollup-plugin-legacy
• rollup-plugin-multi-entry
• rollup-plugin-node-resolve
• rollup-plugin-replace
• rollup-plugin-run
• rollup-plugin-strip
• rollup-plugin-sucrase
• rollup-plugin-typescript
• rollup-plugin-url
• rollup-plugin-virtual
• rollup-plugin-wasm
• rollup-plugin-yaml

Misc

• rollup-pluginutils

In Progress

• rollup-plugin-babel (in progress @Andarist)

Pending

Skip

• rollup-starter-plugin
• rollup-plugin-butternut (deprecated in favor of terser)
• rollup-plugin-node-builtins (was an empty repo, plugin owned by third party)
• rollup-plugin-ractive (Ractive is a dead project)
• rollup-plugin-svelte (will be transferred to @sveltejs)

Before we move a plugin we should:

• Follow up on any open issues.
• Follow up on any pending Pull Requests.
• Add note to the README about the move
• Disable issues and Pull Requests

Give n number of days for response based on age of issue/PR, if there is a reproduction provided, etc.

For each plugin we should:

• Assert there are tests
• Apply linting and clean the code
• Update aged dependencies
• Remove unneeded metadata covered by the monorepo
• Create an issue label for the plugin

After moving a plugin we should:

• Put the plugin repo into an archived state
• Add a deprecation notice to the README and provide URL to the monorepo path for the plugin
• Publish a patch version with the deprecated property added to package.json.

Doesn't work with rollup >= 1.27.0

• Rollup Plugin Name: replace
• Rollup Plugin Version: 2.2.1
• Rollup Version: 1.27.8
• Operating System (or Browser): MacOS
• Node Version: 10.15.3

How Do We Reproduce?

Created a clean project: npm i -y, followed by npm i -d rollup @rollup/plugin-replace, created a small js file with just console.log in it, using the exact rollup.config.js file described under 'Usage' in https://github.com/rollup/plugins/tree/master/packages/replace

Expected Behavior

string replaced in the output

Actual Behavior

string not replaced in the output
warning in terminal: (!) The "transform" hook used by the output plugin replace is a build time hook and will not be run for that plugin. Either this plugin cannot be used as an output plugin, or it should have an option to configure it as an output plugin.

I suspect the problem is related to rollup/rollup#3218
and so I'm guessing it's the documentation of the plugin that needs to be fixed, not the plugin itself.

replace crashes when no values are given

• Rollup Plugin Name: replace
• Rollup Plugin Version: 2.2.0
• Rollup Version: 1.25.2
• Operating System (or Browser):
• Node Version:

How Do We Reproduce?

replace({ values: {} })

Expected Behavior

replace nothing

Actual Behavior

"functionValues[match[1]]" is undefined

Root Cause

plugins/packages/replace/src/index.js

Lines 42 to 48 in 14a4cc7

	const keys = Object.keys(functionValues)
	.sort(longest)
	.map(escape);
	const pattern = delimiters
	? new RegExp(`${escape(delimiters[0])}(${keys.join('|')})${escape(delimiters[1])}`, 'g')
	: new RegExp(`\\b(${keys.join('|')})\\b`, 'g');

When no values are given, keys will be an empty array, and it will create a pattern (/\b()\b/g) that matches empty boundaries ('') with no corresponding functionValues.

Remove jsnext:main support from repo

• Rollup Plugin Name: node-resolve, all others
• Rollup Plugin Version: n / a

Expected Behavior / Situation

n / a

Actual Behavior / Situation

After @TrySound mentioned that jsnext:main is deprecated, I did some digging and asking around. Rollup was really the only bundler that embraced it fully. As mentioned by Rich Harris here, jsnext:main has been superseded by module, and there are numerous sources that consider it deprecated as a result (for example).

Basically it never made it out of discussion, and Rollup supported it out of necessity at the time it was implemented.

Modification Proposal

So all that goes to say is that we have sufficient evidence to remove support from @rollup/node-resolve and to remove that field from any plugins in the repo.

Core-Critical Plugin Script

Create configuration and CI script(s) to identify core-critical plugins that should align with and adhere to the Node versions in the latest version of Rollup. These should prevent publish if out-of-line, and will prevent a plugin from jumping core's supported node version(s).

Recipes (How To) for Common Tasks and Setups

Note: Issue template removed as this is a Repository Management, long-running issue for tracking and action.

With the migration of core plugins to this repo, we're starting to get a birds-eye view of the types of issues that people are running up against with popular plugins. The majority of support requests that make it through to the repo are asking for implementation help. And that seems to stem from a lack of consolidated direction and documentation.

As such, I propose that we create a directory within this repository to house recipes - also known as how-to guides - for common plugin tasks and setups or boilerplating. I've seen this approach be highly effective and recipes become a source of truth for users.

Some initial thoughts on the idea:

• recipes should have a README entrypoint with standard approach, formatting, and layout
• code within recipes should be formatted in similar ways
• recipes should be verbose, using natural language to present more of a conversation with the reader
• recipes should have a standard directory structure when additional files, folders are necessary, and code in files outside of the README should share repo formatting
• runnable recipes (those which have additional files and folders) should have dependencies maintained (we may need an additional script/github action/hook for this)

Questions

• should all recipes be runnable?
• can we get the REPL to support adding plugins to make recipes runnable?

Proposed Recipe Structure

Recipes to be nested within directories that reflect the short plugin name. e.g.

/recipes
  |__ commonjs
  |__ inject
  |__ run

Within each plugin's recipe directory, recipes should be well-named. In cases where there is a common theme or where it makes sense for a parent of similar recipes to exist, additional subdirectories would be acceptable. e.g.

/recipes
  |__ commonjs
      |__ preact
          |__ simple
          |__ replace-react-dom

Comments

Please share additional comments/thoughts. This proposal was inspired by #94 by @mjarkk. For a working recipe example/reference, please see https://github.com/shellscape/webpack-plugin-serve/tree/master/recipes.

/cc @rollup/plugin-contributors @rollup/plugin-maintainers @rollup/core

Plugin Strip is incompatible with TypeScript plugins

• Rollup Plugin Name: Plugin Strip
• Rollup Plugin Version: 1.3.1
• Rollup Version: 1.27.2
• Operating System (or Browser): Windows 10
• Node Version: 12.13.0

How Do We Reproduce?

Create a new project, install rollup, @rollup/plugin-strip, typescript and rollup-plugin-typescript2 (or rollup-plugin-typescript). Create rollup.config.js and add a minimal configuration which includes any typescript file input and the plugins above.
Such as this one:

import strip from '@rollup/plugin-strip';
import ts from 'rollup-plugin-typescript2';  // same issue with rollup-plugin-typescript

export default {
  input: 'input.ts',
  output: {
    file: 'output.bundle.js',
    format: 'cjs',
  },
  plugins: [
    ts(),
    strip(),
  ]
}

Expected Behavior

The plugin should remove debugger, console.*, assert.equal.

Actual Behavior

The plugin doesn't affect the output.

repo task: enable pnpm audit

• Rollup Plugin Name: all plugins
• Rollup Plugin Version: current

Expected Behavior / Situation

n/a

Actual Behavior / Situation

All plugins currently have a placeholder for the "security" script.

Modification Proposal

We need to enable use of pnpm audit. I'm not sure yet how this will work. pnpm may work on the main lockfile only, which would negate the need for the script in each plugin. It may operate on individual package.json files, but that's unlikely.

dedupe leads to errors in a monorepo with hoisted dependencies

• Rollup Plugin Name: @rollup/plugin-node-resolve
• Rollup Plugin Version: 6.0.0
• Rollup Version: 1.27.9
• Operating System (or Browser): macOS
• Node Version: 13.2.0

How Do We Reproduce?

Here is a repo reproducing the issue: https://github.com/jpaquim/rollup-monorepo-issue

Steps:

• Start with a monorepo configuration using package hoisting (the default for yarn workspaces, or using lerna with hoisting enabled)
• Setup rollup and @rollup/plugin-node-resolve in one of the monorepo's packages (let us assume it's in a directory under packages/).
• Configure @rollup/plugin-node-resolve to dedupe a certain package (in my case, I was using sveltejs/template, with dedupe: importee => importee === 'svelte' || importee.startsWith('svelte/') or more simply dedupe: ['svelte', 'svelte/internal'].
• Import the given package in one of the source files
• Bundle using rollup, using as working directory the package directory, and not the monorepo root.

Expected Behavior

The imported package should be correctly bundled with the rest of the output.

Actual Behavior

The imported package is not resolved correctly, rollup complains: (!) Unresolved dependencies https://rollupjs.org/guide/en/#warning-treating-module-as-external-dependency svelte/internal (imported by src/App.svelte)

Consequently, the import statement remains in the output. In my case: import { SvelteComponent, init, safe_not_equal, element, text, space, attr, insert, append, set_data, noop, detach } from 'svelte/internal';

Comments

The issue seems to be related to this line, where the importee is overwritten with join(process.cwd(), 'node_modules', importee).

In a monorepo context, process.cwd() will typically refer to the package where the rollup command is started from, but with hoisting, the relevant node_modules are actually at the root of the monorepo, thus leading to the conflict.

use external

This issue was transferred from rollup-plugin-alias, which lacked an issue template

---

expected:

import a from "../../src/utils/a"

actual:

import a from "win-plus/src/uitls/a

Honor declaration config

It would be nice if the declaration: true flag would be honored in the output.

Alias plugin is not compatible with rollup-plugin-alias

• Rollup Plugin Name: alias
• Rollup Plugin Version: 2.2.0
• Rollup Version: latest
• Operating System (or Browser): unix
• Node Version: 12

How Do We Reproduce?

Add alias({ src: __dirname + '/src' }) to rollup plugins

Expected Behavior

import 'src/util.js' works

Actual Behavior

internal/modules/cjs/loader.js:775
    throw err;
    ^

Error: Cannot find module 'src/util.js'

The API change in plugin-alias@2 breaks the old behaviour for no apparent reason. It's perfectly possible to add a special entries option. It's sad that a project with 20k+ downloads/week can just break dependency upgrades because one developer feels like it.
Breaking PR: rollup/rollup-plugin-alias#53
Previous issue: rollup/rollup-plugin-alias#58
Still incompatible PR: rollup/rollup-plugin-alias#61

(sorry for repeating this issue)

feat: error if there are still imports

Here is my current configuration:

resolve({
  modulesOnly: true,

  // Whitelist imports to assert that we only inline things that we've
  // injected the licenses for.
  only: [
    'indefinite-observable',
    'wobble',
    'symbol-observable',
    'fast-equals',
   ],
}),

I'm interested in adding a check that will throw if there are still import statements in the resulting bundle (e.g. exhaustive: true). The purpose of such a check would be to require a manual intervention before adding any dependencies to a published bundle: in this case, to ensure that the correct licenses have also been included.

Would you be amenable to a patch to support this, or should I make a separate plugin?

(migrated from rollup/rollup-plugin-node-resolve#188)

TypeError: Cannot read property 'resolve' of undefined

Plugin: rollup-plugin-commonjs

Plugin Version: 10.1.0

Rollup Version: 1.27.2

Operating System (or Browser): Windows 10

Node Version: 12.13.0

How Do We Reproduce?

Reproduction steps are outlined in this reduced test case repo:

https://github.com/Dan503/BUG-rollup-plugin-node-resolve/tree/CommonJS-bug

Note this part of gulpfile.js in particular:

const rollupJS = (inputFile, options) => {
	return () => {
		return (
			rollup({
				input: options.basePath + inputFile,
				format: options.format,
				sourcemap: options.sourcemap,
				plugins: [
					CommonJS(), // <<-- This is the line that calls rollup-plugin-commonjs
				],
			})
				.pipe(source(inputFile, options.basePath))
				.pipe(buffer())
				.pipe(sourcemaps.init({ loadMaps: true }))
				.pipe(sourcemaps.write('.'))
				.pipe(gulp.dest(options.distPath))
		)
	}
}

Expected Behavior

It should not error.

Actual Behavior

It throws this error when trying to run the code:

TypeError: Cannot read property 'resolve' of undefined
    at resolveId (C:\xxx\node_modules\rollup-plugin-commonjs\dist\rollup-plugin-commonjs.cjs.js:157:17)
    at C:\xxx\node_modules\rollup-stream\node_modules\rollup\dist\rollup.js:1750:32
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

plugin not found on npm

$ npm install @rollup/plugin-inject --save-dev
npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@rollup%2fplugin-inject - Not found
npm ERR! 404 
npm ERR! 404  '@rollup/plugin-inject@latest' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ettinger/.npm/_logs/2019-11-20T19_08_50_855Z-debug.log

Repo Setup Tasks

Tasks that have been identified as required to make this repository functional.

• Copy .github from rollup/rollup and customize
• Copy CI from rollup/rollup
• Configure CI to only build tests from changed paths (this will be tricky)
• Install rush and configure. Rush is the prevailing favorite for monorepo management. We'd like to give it a shot. Use of pnpm under the covers is compelling.
• Install and setup pnpm for monorepo management
• Copy the TypeScript configuration from rollup/rollup
• Create @rollup/eslint-config using tslint-to-eslint-config and the tslint config from rollup/rollup
• Pull in a good .editorconfig
• Install ava, nyc, and create a demo plugin to demo tests. (I would like to try out ava here. It's very solid, very fast, has wonderful snapshot support, and works well for libraryish projects)
• Create configuration and CI script(s) to identify core-critical plugins that should align with and adhere to the Node versions in the latest version of Rollup. These should prevent publish if out-of-line, and will prevent a plugin from jumping core's supported node version(s).

Note to maintainers: If you'd like to see a task listed here, please edit the OP and add it, and provide a followup comment with what was added, for visibility.

Wrong complierOptions when tsconfig in cwd is extended from another tsconfig

For example:

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "./dist",
    "declaration": false
  }
}

Seems that rollup-plugin-typescript does not try to resolve the base tsconfig, so that the compilerOptions is not extended.

auto-install yarn tests

• Rollup Plugin Name: auto-install
• Rollup Plugin Version: latest

Expected Behavior / Situation

I'd really enjoy it if the tests passed consistently. I frequently have to rerun the Circle CI workflows because of failed yarn tests.

Actual Behavior / Situation

☝️ same same

Modification Proposal

I'd like to nuke the yarn test that is failing intermittently. If someone can spot a way to get it working 100% of the time, I'm all for it.

Thoughts?

/cc @rollup/plugin-contributors @rollup/plugin-maintainers

es6 compile error (aperator OF)

• Rollup Plugin Name: @rollup/plugin-buble
• Rollup Plugin Version: 0.20.0
• Rollup Version:1.1.2
• Operating System (or Browser):
• Node Version:

How Do We Reproduce?

cant compile this code:

for (var key of data.keys()) {
\ iteration of FormData
}

https://developer.mozilla.org/ru/docs/Web/API/FormData/keys

Expected Behavior

compile

Actual Behavior

Error

UnhandledPromiseRejectionWarning: Error
at Function.missingTransform (\node_modules@rollup\plugin-buble\node_modules\buble\dist\buble.cjs.js:376:9)

deep imports not deduped

• Rollup Plugin Name: @rollup/plugin-node-resolve
• Rollup Plugin Version: 6.0.0
• Rollup Version: 1.27.13
• Operating System (or Browser): macOS Sierra
• Node Version: 10.16.0

How Do We Reproduce?

• Create a package called foo with two files:

shallow.js:

console.log('shallow.js');

deep/deep.js:

console.log('deep/deep.js');

• Create a package called bar, with a dependency on foo 1.0.0
• Create a package called buz, with a dependency on foo 2.0.0
• Create a main export for both bar and buz with this content:

import * from 'foo/root.js';
import * from 'foo/deep/deep.js';

• Create a project which depends on bar and buz
• Create an app.js file:

import 'bar';
import 'buz';

• Create a rollup config:

import resolve from '@rollup/plugin-node-resolve';

export default {
  input: 'app.js',
  output: {
    dir: 'output',
  },
  plugins: [resolve({
    dedupe: ['foo']
  })]
};

Expected Behavior

Both shallow.js and foo/deep/deep.js are deduplicated.

Actual Behavior

Only shallow.js is deduplicated. This is because the dedupe option of rollup-plugin-node-resolve uses a literal match to find out whether an import should be deduplicated (imported from root): https://github.com/rollup/plugins/blob/master/packages/node-resolve/src/index.js#L168

I don't think this intentional behavior, people would expect deduplication to happen on a package level.

A fix can be to look at the package name, which is guaranteed to be either the first part of an import path, or the first two is the first part is a scope starting with @. I can work on a PR if that's the intended solution.

Provide option to strip comments from JSON files (JSONC)

• Rollup Plugin Name: @rollup/plugin-json
• Rollup Plugin Version: 4.0.0

Feature Use Case

Comments in JSON are a thing. While one can strip comments from JSON files before passing contents to the json plugin it would be nice if the plugin provided this an option for convenience sake.

Feature Proposal

You could leverage the strip-json-comments module or use an expression (something like ^[^"{}[\],]*?\/\*?\/?.*?(?:\*\/)?$would maybe suffice ) – either way you get the point. Probably best to provide as an opt in to prevent files being parsed for comments by default.

Provide a `safeLoadAll` option

Hi, I have a stream which has multiple documents inside e.g:

---
kind: x
apiVersion: v1
spec:
  selector: example1
---
kind: x
apiVersion: v1
spec:
  selector: example2
---
kind: x
apiVersion: v1
spec:
  selector: example3

in the plugin you have:

let data = YAML.load(yaml);

but this causes this error when loading my file (plugin yaml) YAMLException: expected a single document in the stream, but found more.

For my workflow I need an option to have it loaded as

let data = YAML.safeLoadAll(yaml);

This will load both single and multiple document streams

thanks in advance 🙌🏻

filename missing when using getBabelOutputPlugin

When using babel.generated, the filename is not being provided to the babel options. https://github.com/rollup/rollup-plugin-babel/blob/master/src/index.js#L182. I think outputOptions.dir + chunk.fileName should give the appropriate filename.

typescript plugin does not recognize typescript code

• Rollup Plugin Name: plugin-typescript
• Rollup Plugin Version: 2.0.1
• Rollup Version: 1.27.8
• Operating System (or Browser): Mac OS X Catalina
• Node Version: 12.13.1

How Do We Reproduce?

I have created a minimal github repo here:

https://github.com/quentinadam/test-rollup-typescript

Compile with rollup by running npm run build or rollup -c

Expected Behavior

Should compile the typescript code into a javascript bundle.

Actual Behavior

Errors with compilation (such as Error: The keyword 'private' is reserved (Note that you need plugins to import files that are not JavaScript) which show that the typescript code is not recognized.

alias.resolve doesn't work for svelte 3

• Rollup Plugin Name: @rollup/plugin-alias
• Rollup Plugin Version: 2.2.0
• Rollup Version: 1.26.0
• Operating System (or Browser): os win 10 firefox
• Node Version: v10.13.0

How Do We Reproduce?

rollup config:

export default {
 ...
plugins: [
 alias({ 
            resolve: ['.js','.svelte' ],
            entries: [
                {find:'@', replacement:'src'}
            ]            
        })
]
}

Expected Behavior

UiAlertTag shoud be imported

<script>
 // Target file: ...UiAlertTag.svelte

  import UiAlertTag from "@/core/widget/UiAlertTag"; // does not work. Error: coudn't open file...
//   import UiAlertTag from "@/core/widget/UiAlertTag.svelte";  // this is ok.
</script>

Actual Behavior

[!] (plugin Rollup Core) Error: Could not load src/core/widget/UiAlertTag (imported by c:\MyProjects\my\armario\app-webui\src\directory\pages\trademark\UpdateTrademark.svelte): ENOENT: no such file or directory, open 'c:\MyProjects\my\armario\app-webui\src\core\widget\UiAlertTag'
Error: Could not load src/core/widget/UiAlertTag (imported by c:\MyProjects\my\armario\app-webui\src\directory\pages\trademark\UpdateTrademark.svelte): ENOENT: no such file or directory, open 'c:\MyProjects\my\armario\app-webui\src\core\widget\UiAlertTag'

Update recommendations on compiling external dependencies

I think the advice to not compile external dependencies is a bit outdated and could use some clarification.

Native implementations of ES2015+ are now faster than down-leveled ES5 equivalents, and the code is smaller over the wire. This is especially true with generators and async functions. Many native features, like extending built-ins, only work with native classes.

The last two versions of all major browsers, as well as Node.js, support all of ES2017. End users will benefit from smaller, faster JS bundles. Users on slower networks and devices will benefit the most. Applications can compile first- and third-party code to whatever language level they require, but third-party cannot know what language levels applications support ahead of time, and so pre-compiling them will result in a degraded experience for most users.

Two things about the current recommendations:

We encourage library authors not to distribute code that uses untranspiled ES6 features (other than modules) for this reason. Consumers of your library should not have to transpile your ES6 code, any more than they should have to transpile your CoffeeScript, ClojureScript or TypeScript.

CoffeeScript, ClojureScript are TypeScript are not JavaScript, and always have to be compiled, so the comparison is very flawed. Packages can publish standard JS (to a widely-supported language version, like ES2017), and applications can compile as necessary to their supported target environments.

Use babelrc: false to prevent Babel from using local (i.e. to your external dependencies) .babelrc files, relying instead on the configuration you pass in.

Hopefully packages are not publishing .babelrc to npm, as this is the configuration they used before publishing. I would hope in the cases where they accidentally did, that the default would be to ignore it.

I would suggest that either the recommendation against ES2015 is just removed, or ideally replaced with a recommendation to publish ES2017, and some of the rationale for it.