Add option to overwrite or extend default configs.

[wladi0097]

I love microbundle but sometimes we really would need a custom plugin or to overwrite a rollup config.
Therefore I would suggest the following:

new cli option:

--extendRollupConfig 'extend.js'

example extend file:

// extend.js (must return RollupConfig)
return {
  plugins: [
    myCoolPlugin() // Add new
    terser({...}) // Overwrite terser plugin
  ]
  outputOptions: {
    systemNullSetters: true
  }
}

The original config stays the same, but can be overridden if needed. Otherwise it is just extended.
I could take care of the implementation.

What do you think ?

[developit]

The problem is that this makes it impossible to control versioning or change any of the libraries Microbundle uses to build things. It's probably better to use a custom Rollup config in such cases.

[wladi0097]

@developit could you elaborate how this would make microbundle changes more complicated ?

On override: The original library is not used and therefore changes on that have no affect.
On newly added plugin: nothing on the side of microbundle is used and its just appended.

The only real issue I can think of, is when microbundle has a new rollup plugin, but this can be easily be fixed like:

// microbundle/src/index.js
const config = {
  options.override.coolPlugin || coolPlugin({
    config: 'default from microbundle in this case'
  })
  [....]
}
Object.assing(config, options.override.pluginsWhichMicrobundleDoesNotUse)

Rollup(config)

:D

[developit]

The issue is not conflicting plugins, it is leaking plugin execution itself. If Microbundle exposes Rollup, Micrbundle's version is now tied directly to Rollup's, as well as any of the Rollup plugins it uses.

Rollup plugins near-universally interact with other plugins (via nested resolve() or transform() sequences), and this can easily break when updating internal dependencies.

[frank-dspeed]

Hi Inventor of the Stealify Component system here which in fact implements a lot of Rollup Concepts.

we are going with the Component Pattern that means every package or anything that we load is a rollup plugin it self we implement the rollupPlugin Context and import a component

we treat plugins as build components. This allows us to build all our components with a unified pattern we can do

stealify build component:<PATH or URLPath without protocol> 

that translates to

import { rollup } from 'rollup';
import { componentName } from 'component:<PATH or URLPath without protocol>';

rollup({ plugins: [componentName()]}).then(b=>b.write());

when i now want to create bundels out of a component that what you refer as a MicroBundle which we refer to as a Task
that looks internal like that

import { rollup } from 'rollup';
const { componentName } = { componentName() {
  return { buildStart() {
 
    rollup.rollup({}).then(b=>b.map(this.emitFile))

}};

rollup({ plugins: [componentName()]}).then(b=>b.write());

at present we have greate success with that pattern but we emit opinionated only assets from components you can break that rule in your implementation but we found it usefull to turn the resulting sub bundels which we call in our case also components into asset types so that the main that processes the components in your case rollup in our case our component manager handels only assets on the higher level which do always got a clear specifier and do not get processed anymore.

Maybe shorter and more none technical

Build MicroBundels out of Plugins that wrap the build result into a final generateBundle hook that returns only assets simply change the type and fildName in the bundle you can compose Out of that unlimited micro bundels that you can always manipulate via Plugins that only use a generateBundle hook to transform the results.

Advanced tip

Assets can be the Source input of Chunks that you can create via emitFile this gets used in stealify components to implement layered source maps which are use able indipendent.

This also bypasses in our case the most time the resolve hooks as we simple know the files are in the same directory as our component which is a plugin definition.

in stealify a component is equal to a system plugin so ``ìmport.meta.url``` always is the baseUrl