Give better insight in what is going on

[EmielM]

This is not a specific bug or feature request, but hopefully more of a discussion point. I've had serious day-long fights with getting rollup to behave the way I wanted, and ultimately ended up with a custom debug build littered with console.log only to get an idea of what the hell is going on.

There are, I believe, a number of reasons for this:

• The architecture of rollup is hard to grasp from the wiki or even the source code. In fact, I still don't understand fully why/how/when data is flowing through the different parts and/or plugins.

• A "plugin" in the context of rollup can mean a lot of different things and they are often not composable (try using includepaths with node-resolve). Reasoning about plugin ordering is bizarre (node-resolve and typescript, in which order? Apparently .ts needs to be added as extension for node-resolve when used together -- why?)

• Sometimes plugins aren't just very usable (typescript comes to mind, it just doesn't really work with error reporting -- the primary reason a lot of people use typescript to begin with).

• Plugins are of questionable code quality - they seem slapped together by some crazy copy/pasting, are scarcely commented and often have insane dependencies (file-as-blob imports the entire imagemagick hell just to check for a magic byte the start of a resource).

• In the NPM ecosystem today, developers really like to add 10 dependencies instead of adding 10 lines to their code. For rollup this means there's a lot of work to do, but in my opinion lacks the proper tools to figure out why my output file has suddenly ballooned to 1m lines (ah, lodash is apparently included, why?).

I could imagine that adding better tooling (verbose logging, dependency graph output, see what a plugin is doing) in rollup would be very welcome in the js ecosystem today and make developing for it a lot more bearable.

[kzc]

Yeah, a verbose mode would be quite useful:

• output each module name being imported with complete path just to see what's getting pulled into a bundle - probably the most frequent cause of problems.
• output plugin name being run on what file
• optionally tee output between plugins to see what's going on (side question - is there a plugin that can simply tee without changing the code?)
• output which symbols are being dropped (functions, classes, variables) complete with file/line info.

[tivac]

I did slap together a simple plugin that tries to report on files being bundled and their sizes that works directly w/ the rollup plugin API. It's not nearly as thorough as what is being proposed here but it's something.

https://github.com/danvk/source-map-explorer uses the sourcemaps to let you visually inspect the contents of the output bundles and is super-cool as well.

[kzc]

@tivac Thanks for the source-map-explorer link - it's fantastic:

https://cdn.rawgit.com/danvk/source-map-explorer/08b0e130cb9345f9061760bf8a8d9136ea60b457/demo-bug.html

[Rich-Harris]

This is all good feedback, thanks. Some of this stuff is definitely on the roadmap — see for for example

• this.warn(...) (and others) for plugins #1140 (better errors/warnings for plugins, which we're in a better place to implement following [WIP] [BREAKING] Better warnings #1199 and [WIP] [BREAKING] More consistent error logging, with code frames etc #1212)
• Feature Request: CLI debug logging #651, which would build on top of some of the ideas in plugins like @tivac's (we need to figure out which bits of logging belong in core and which belong in plugins, but the will is certainly there)
• Plugin order #1148, because plugin order is indeed a source of confusion

Apparently .ts needs to be added as extension for node-resolve when used together -- why?)

Getting plugins to co-ordinate is a very hard problem. To handle that specific case, we'd basically need to add an API that allowed plugins to dictate which extensions were supported and that would allow other plugins to tap into that configuration. Doable, but I think it's a bad idea — I've always said that at some point we should disable support for extensionless imports (obviously plugins like node-resolve would still work, but ./foo without a resolver plugin wouldn't), because frankly they're a terrible no good very bad idea, and a masterclass in how design decisions that are made to make developers' lives slightly easier can end up having far-reaching negative consequences for years afterwards. (Also, since native module ID resolvers are unlikely to support extensionless imports, nor should we!)

optionally tee output between plugins to see what's going on (side question - is there a plugin that can simply tee without changing the code?)

This is cheating, but I'll often do this sort of thing:

// rollup.config.js
export default {
  plugins: [
    thisPlugin(),
    {
      transform ( code, id ) {
        console.log( id );
        console.log( code );
        // not returning anything, so doesn't affect bundle
      }
    },
    thatPlugin()
  ],
  // other options
}

Would be easy enough to create a rollup-plugin-tee that did that in a slightly neater way, optionally writing to a file etc.

[btd]

Maybe this would help. I created some time ago plugin for myself to see what is taking space in bundles.