Share `sourcemap` option to plugins

[mjeanroy]

Hi,

I'm opening the issue to start a discussion about sharing the sourcemap configuration between rollup and plugins.

For example, here is a "classic" configuration. As a rollup user, I have to disable sourcemap option in rollup configuration, and for each plugins:

const babel = require('rollup-plugin-babel');
const commonjs = require('rollup-plugin-commonjs');
const nodeResolve = require('rollup-plugin-node-resolve');

module.exports = {
  input: './src/index.js',

  output: {
    file: './dist/bundle.js',
    sourcemap: false,
  },

  plugins: [
    nodeResolve(),

    babel({
      sourceMap: false,
    }),

    commonjs({
      sourceMap: false,
    }),
  ],
};

There are two kinds of plugins that need the sourcemap configuration: plugins that implement the transform and/or the transformBundle function.

@Rich-Harris Not sure what is the best way to implement it, but I would be happy to send a pull request if you have an idea.

[Rich-Harris]

To be honest I think this is something that has to be handled by each plugin separately, using the options hook:

export default function myPlugin(opts = {}) {
  let sourcemap;
  return {
    name: 'my-plugin',

    options(bundleOpts) {
      sourcemap = 'sourcemap' in opts ?
        opts.sourcemap :
        bundleOpts.sourcemap !== false;
    },

    transform(code, id) {
      return compile(code, { sourcemap });
    }
  };
};

[mjeanroy]

Hi @Rich-Harris,

Thanks for your response.
I'm already doing this in custom plugins and I think it should probably be documented in the wiki.

That said, your solution does not work

• If the sourcemap option is set in the output configuration as documented in your gist (but your code can be updated easily).
• If the sourcemap is disabled for a bundle in the output array, then plugins overriding the transformBundle can't know if sourcemap should be enabled or not. For example:

module.exports = {
  input: './src/index.js',
  output: [
    { file: './dist/bundle.js', format: 'es', sourcemap: false },
    { file: './dist/bundle.debug.js', format: 'es', sourcemap: true },
  ],
};

Maybe, the sourcemap option should be pass to the transformBundle function such as the format option. What do you think?

[alex-kinokon]

Is there any way I can transformBundle while preserving the source map?

[mjeanroy]

Hi @lukastaegert,

Since version 0.53, it is no longer possible to read the sourcemap option in plugins since the output configuration is no more available when the plugin.options function is executed: two plugins I wrote are currently broken (rollup-plugin-prettier and rollup-plugin-esformatter).

I think, this is due to this commit since the result of mergedOptions is being passed to the plugins.options function (loosing the output entry).

Is that something deprecated? Do you recommend an alternative to get the output option?

Note: I still think that passing the output options to the transformBundle function would be great, and I would be happy to submit a pull request if you are interested

Thanks for the hard work!

[lukastaegert]

Please do submit a PR! I must admit I no longer have the grand overview today and will probably not find too much time during the next days to look into this further, though. Note, however, that you should probably raise a PR against the TypeScript PR as I hope we might merge this as early as tomorrow. Otherwise, maybe @ankeetmaini wants to take a look at this.

[ankeetmaini]

I looked into it, and passing sourcemap would be difficult in inputOptions as Rollup's Node API doesn't require you to pass all the options. And as users would eventually migrate to Rich's unified options gist we may not have it at all.

One thing that we can do is pass the output options in transformBundle function. I did some work here #1808

[mjeanroy]

Hi @lukastaegert,
I looked at #1808 and I commented here, but @ankeetmaini PR is exactly what I need :)

[jdalton]

Is there a way to do this now? None of the posted solutions seem to work at this time.

[shellscape]

@jdalton given the age of the OP I'd recommend a new documentation issue with some use case for flavor.