Suggested improvements
getdave opened this issue · comments
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.
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.