dazinator/NetPack

Add support for Rollup

Closed this issue · 8 comments

dazinator commented
  • Produce a single output bundle from a set of files, and an entry point.
  • Produce multiple seperate bundles, using code splitting
  • Allow any rollup plugins to be configured.
  • Source Maps
  • Output Name (The variable name, representing your iife/umd bundle, by which other scripts on the same page can access it.)
  • External. (An Array of module IDs that should remain external to the bundle)
  • Globals (Object of id: name pairs, used for umd/iife bundles.)
  • Output Paths (i.e to allow load from CDN)
  • Output.amd.id (used to configure module id (default is anonymous) when the bundle output format is AMD).
  • cache
  • Multiple Output formats from single set of inputs (i.e send input files once, produce multiple different bundle files such as ESM, and System etc. (In Progress)
dazinator commented

Looks like for the in memory file system I can use: https://github.com/Permutatrix/rollup-plugin-hypothetical

dazinator commented

Lots of rollup plugins here: https://github.com/rollup/awesome

dazinator commented

Tests passing over at https://github.com/dazinator/NetPack-Rollup/tree/develop
Can now start to think about the C# API

dazinator commented

One area of concern is that rollup has a fountain of optional plugins that can be incorporated into its build process, for handling things like typescript, or html, or images etc.

Each of these plugins, could be of use. So the .NET API in NetPack, for invoking rollup, needs to allow for this "inclusion" of any rollup plugins that you might want to participate in the rollup build process.

I imagine this will either be surfaced via a combination of strongly typed configuration methods for addign well-known plugins, overlaying, a dynamic structure that allows a dependency on a rollup plugin to be expressed, along with some configuration for that plugin, possibly in the form of JSON.

One "Plugin" for rollup that is included by default in order for netpack to work, is an In-Memory file system called Hypothetical. I need to include this by default because files are sent to the node process via a socket, and a virtual directory is built in memory. I do not want files read from disk. This has some benefits.

dazinator commented

On the node side, adding a plugin into the rollup build process looks like this:

import fooPlugin from 'rollup-plugin-foo';
var pluginOptions = {};
var pluginInstance = fooPlugin(pluginOptions);

var rollupOptions = {
   ``` omitted for brevity 
  plugins: [
    pluginInstance
  ]
};

So on the .NET side, you need to send name of the plugin to be imported e.g from above would be rollup-plugin-foo, as well as the configuration to pass when creating an instance of the plugin, this configuration would be a JSON object. On the node side, will just instantiate the plugins adding them to the plugins array in the order passed.

This should allow arbitrary plugins to be included, however on the .NET side I could also offer fluent / strongly typed configuration methods for particular plugin configuration, which would be surfaced over the raw JSON configuration object.

dazinator commented

It appears that this plugin, if you give it a path to requirejs config file, it tries to load it from disk, it doesn't load file using rollup's mechanism which allows support for in memory file systems.

I can work around this in my AMD example, by passing an object perhaps instead of the file path.

dazinator commented

Consider a demo page also dealing with css: https://code.lengstorf.com/learn-rollup-css/