Suggested improvements

[Dave Smith]

Great work on the accordion Stu. Fantastic to see it launched. Some constructive feedback

Env Vars

Add in env vars to distinguish between "dev" and "production" builds (ie: whether Rollup is building to aid you in development or whether you're building a final package for consumption by users).

import replace from 'rollup-plugin-replace';

...
export default {
  ...
  plugins: [
    ...
    replace({
      ENV: JSON.stringify(process.env.NODE_ENV || 'development'),
    }),
  ],
};

Then you can prepend whatever command you're using to run the rollup build with the correct ENV setting. Eg:

NODE_ENV=production rollup

Apply Plugins Conditionally

I notice you have uglify commented out. Once you have implemented the above then you can conditionally apply the plugins as follows

export default {
  ...
  plugins: [
    ...
    replace({
      ENV: JSON.stringify(process.env.NODE_ENV || 'development'),
    }),
    (process.env.NODE_ENV === 'production' && uglify()),
  ],
};

Use scripts

I notice there is no indication as to how you're running the rollup commands. You can use the scripts section (docs) of package.json for this.

For example,

"scripts": {
	"dev": "NODE_ENV=develop ./node_modules/.bin/rollup -c",
	"build": "NODE_ENV=production ./node_modules/.bin/rollup -c" // args and config would probably be different between dev and production
}

Use module field

Apparently you should add a module field to the package.json which points to your ES Module file. That will allow ES6-aware tools like Rollup and webpack 2 to import the ES6 module version directly. You are correct to point the main field to the bundled output version.

Array.from polyfill

In some ways you are right to not bundle the Array.from into your code. This avoids the small perf penalty people have to pay if they already have it polyfilled. That being said, not bundling it assumes people will read your docs...they may well not.

Given the size of the plugin I would suggest you just bundle it. It should be wrapped in a conditional (check the output matches something like this example) to ensure it's not applied if it's already polyfilled. If it becomes a problem you could always look to create a bundle with and without the polyfill. This would be fairly simple. You could just create x2 main files and have these import badger script, but include/excluding the polyfill before the import. This would produce x2 output files - one with and one without the polyfill. Just an idea.

[Stuart Nelson]

Thanks for all this Dave. Super helpful. I think I got the module field and .esm file sorted out correctly... I decided to roll the polyfill in for now as its tiny and the plugin is small anyways.