Skip to content

Bundling Strawman

Jump to bottom
Andy Berry edited this page Nov 8, 2013 · 3 revisions

Design Goals

  • Developers should be able to use a logical tag for inclusion of a bundle containing all resources of a particular mime-type (e.g. 'text/javascript'), so that blades can be dropped-in to existing applications regardless of the underlying technologies (e.g. LessCSS) they opt to use.
  • The bundler-plugin for a particular mime-type will normally generate a single set of bundle requests optimized for the given scenario (e.g. development or prodoction), but must also allow bundle-sources that require it (e.g. the TypeScript bundle-source) to require additional bundle requests to be made if this better suits their mode of operation (e.g. TypeScript wouldn't be able to support the serving of individual files in development, but OTOH would be able to support the serving of source-maps to make debugging easier).
  • The model must cater for the fact that bundle-source plugins will cause new file extensions and/or file locations to become relevant when determining the bundle-set for a given request.
  • Bundlers will sometimes provide attributes that work for the optimized set of bundler requests; bundle-sources should attempt to honour these attributes whenever possible for an out-of-band requests, and bundlers should be careful that the settings they do provide could be sensibly supported out-of-band wherever possible.
  • The bundle-sources need to act as the factory for creating instances of SourceFile, SeedAssetFile & AssetFile that act appropriately, and whether a particular bundle-source factory is used can not be determined solely by file extension (e.g. 'src/**.js' must be handled differently to 'legacy-src/**.js').
  • The BundlableNode.getBundleSet() method should not need to be invoked multiple times to handle a single bundle request from the browser.
  • We can also use file-transform-plugins to cheaply manipulate the contents of a file before it is read by the bundle-source, or the bundler-plugin, but these come with a number of limitations:
  • They are only re-run if that particular file has changed.
  • They must be able to do any work independent of the content of any source other file, or files.
  • Any transforms will not be represented within a source map, even if the bundler-plugin or bundle-source that consumes the content supports source maps.

Proposal

I propose the following source code locations:

  • 'src/' (Node style classes)
  • 'caplin-src/' (Caplin style classes)
  • 'lib/package.json' (Node style libs)
  • 'lib/' (Non-node conformant libs)

An example of a logical tag that might be supported by a bundler is this:

<@js.bundle dev-minification="none" prod-minification="closure-simple"@/>

The following plug-in interfaces will be required:

  • FileTransformPlugin
  • BundleSourcePlugin
  • BundlerPlugin (which must also provide a BunlderTagPlugin implementation)

Bundler Source Map Support

Clone this wiki locally