Caching and user-supplied modules about rollup HOT 5 CLOSED

[...] there will be times when we want to supply a module's contents [...]

By supply a module's contents, do you mean through some user-supplied module object that implements some Module interface? Specifying, or at least starting to consider, what such an interface would look like is very interesting. We discussed it briefly in #99, when I tried to present the advantages of a DataModule (and more specifically a JSONModule).

An interface somewhat like this (written in TypeScript) would probably be a good start.

// A top-level identifier within the bundle.
interface Id {
  // The deconflicted name to use for the `Id`.
  name: string;

  // The `Module` instance which defines the `Id`.
  // ( `undefined` in the case of global identifiers. )
  // If the `Id` is itself a `Module` the invariant `this.module === this` must hold.
  module?: Module;

  // Mark the identifier for inclusion
  // In the case of modules, marks that its exports must be dynamically accessible.
  //     import * as m from './module.special';
  //     console.log( m[ unknownValue ] );
  mark(): void;
}

interface Module extends Id {
  id: string; // the module id
  exports: Scope<Id>; // a scope in which to lookup the exported identifiers

  // Returns two StringSets of which modules this module depends on, strongly and weakly.
  consolidateDependencies(): Dependencies;

  // The `toExport` is a map from deconflicted name to an assignable,
  // likewise readable, expression e.g. `{ '_a': 'exports.a' }`.
  // The `direct` flag indicates whether imports from external modules can be
  // accessed directly, or if they must be a member expression.
  // e.g. `path.resolve`.
  render( toExport: StringMap<string>, direct: boolean ): string;
}

// Other, implicit types...

interface Dependencies {
  strongDependencies: StringSet;
  weakDependencies: StringSet;
}

interface StringMap<T> {
  [ key: string ]: T;
}

from rollup.

No, I was thinking of something much more simple – supplying the (JavaScript) source code of a module without it being loaded from disk, e.g. in a browser setting. At the moment it's done like this but it could be more declarative (this is in fact made easier by #108, since someone could have a custom loader but still take advantage of a default loader that inspected e.g. options.modules).

I think we'd make life for our future selves difficult if we tried to make modules extensible like that – it'd be highly complex and restrict our future freedom of movement. Ultimately, everything has to get turned to JavaScript anyway, so I reckon a better route would be to improve the transformation process (i.e. #107).

from rollup.

Perhaps you're right. I might have gotten stuck on that idea of being able include a handpicked set of static data...

from rollup.

Would be nice to be able to feed in modules with lists of dependencies and ASTs. Most of the overhead in production-oriented build tooling seems to come down to every tool having to re-parse large amounts of the tree.

If rollup exposed such an API (apologies if it does already) it would make it a lot more viable to include with other build tools.

from rollup.

I'm going to close this issue now as it's rather out of date – loading modules from memory is trivial with plugins

from rollup.