Add possibility to disable code splitting / chunks generation

[vladshcherbin]

Feature Use Case

input: [
  'src/server/one.js',
  'src/server/two.js'
]

The code above will create chunks when both files have same imports. Sometimes it's not desired, for example when each file needs to be self-contained (serverless). It would be nice to be able to turn code splitting off.

Using array in rollup config is not desired as it creates difficulties in working with plugins.

Feature Proposal

Add config option to turn code splitting feature off.

[lukastaegert]

This is not a documentation issue. It is not possible to build several overlapping targets in the same build without code-splitting. One core principle in Rollup's architecture is at the moment that each module exists only once.
Thus an array is the only option for now.

I see however the benefit of being able to do that, which would be performance: As we are sharing the same input options, shared modules do not need to be loaded, transformed or parsed again. In the future, we might consider adding an option to mark entry points as "standalone" to the effect that those entry points are handled in a separate build phase that shares the same parsed modules.

[vladshcherbin]

@lukastaegert yeah, this turned out to cause a lot of difficulties for me.

For server code, I don't need chunks. Array in config makes it hard to work with plugins as they run multiple times with different context.

Same for browser, I can't have an iife build with an object with 2 entries as input because it gives error:

Error: UMD and IIFE output formats are not supported for code-splitting builds

*changed issue to a feature request

[shellscape]

@lukastaegert thoughts on the state of this one?

[lukastaegert]

At the moment this is lower priority. I would prefer to put more work in a cache plugin API that could be utilised by the CLI to share information between builds in an array of inputs. If this is done, it could be possible to reintroduce this as a CLI feature.

[mpcref]

IMHO it would be more intuitive to simply disable the code-splitting feature for module formats for which this feature isn't supported and just build the modules without chunks. Maybe with a warning or by requiring a force flag?

[alshdavid]

When trying to build a umd formatted library for npm with preserveModules: true I am greeted with

Error: UMD and IIFE output formats are not supported for code-splitting builds

Obviously, this is a library for npm so I don't want or need code splitting in this context - I just need maximum import compatibility.

export default {
  input: `src/index.ts`,
  preserveModules: true,
  output: {
    format: 'umd',
    dir: './dist'
  },
  external: [],
  watch: {
    include: 'src/**',
  },
  plugins: [
    json(),
    typescript({ useTsconfigDeclarationDir: true }),
    commonjs(),
    resolve(),
    sourceMaps(),
  ],
}

[lukastaegert]

The whole point of preserveModules is to generate multiple chunks and is inherently incompatible with a UMD of IIFE output. If you do not need it, do not use it.

[alshdavid]

You're right, I mistakenly thought webpack wouldn't read import/export syntax in node_modules

[webpepper]

I've just hit the same roadblock. I'm building a serverless application in which I want standalone files (bundles) in the end. In my case I don't want any imports, I want all the required code in the same file: one source file = one completely standalone compiled file. X input files = X outputs files. Currently it seems that with multiple inputs the bundler... doesn't actually bundle everything.

A semi-working solution is to export multiple configs from rollup config, i.e. module.exports = [{}, {}, {}] but it gets slower and uses crazy amounts of memory with each additional input. It worked great in the beginning when there were a couple of input files, but now the build process is very slow and crashes at times even when running with node's --max-old-space-size flag.

Another solution is to put all these shared modules (output chunks) into a separate folder and include them with every single serverless function. You end up including unneeded code in your serverless functions. So this is a suboptimal solution too.

{
    input: [ { function1: 'src/function1.js', function2: 'src/function2.js' } ],
    output: {
       entryFileNames: '[name].js',
       chunkFileNames: 'includes/[hash].js',
    }
}

When deploying you have to copy this entire includes (or whatever you name it) folder with every function because you don't know which files exactly will be needed.