à la carte vs buffet

[bahrus]

I'm hoping this scenario has already been thought through, but I just can't find where it's been explicitly stated:

It's wonderful when a library can separate cleanly into individual functions, and applications can pick and choose just what they need. This works best for silo'd applications, of which there's certainly a huge demand. However, particularly in intranet settings, this principle yields diminishing returns, as the

• Size of the organization increases, and
• Despite the large size, there's a desire to keep the library choices constrained, to allow employees to move easily from one group to another
• Teams build their own applications, according to their own release schedule (thus having one giant build is impractical) but
• Their applications are linked together via iframes or regular links.

In this situation, a common CDN is quite useful, with perhaps an incentive to only support major releases of these libraries, so applications will more likely tend to converge on the same version (and help provide some semblance of "governance" over library choices).

The problem is those individual files with individual functions now become problematic. In this scenario, we really need to think of the "lodash" library, or the "date-fns" library, with perhaps a few common packages built from them.

It would be good if the package-name-map could make this easy to manage. Something like:

"lodash": { "path": "lodash/*", "main": "lodash_bundled.js" }

[domenic]

I'm not sure I quite understand, but did you see from the readme how a package already consists of multiple modules, only one of which is the main module? That should cover the many-module packages like lodash.

[bahrus]

I'm sure I'm the one who doesn't understand:

I just want to make sure than application developer can write in a JavaScript file that gets shipped to the browser, with this syntax:

import {isDate} from 'lodash/isDate.js';
import {isRegularExpression} from 'lodash/isRegExp.js';

That with the help of a package map, the browser will be able to make a single http request, to a single bundled file of the lodash library.

And to do so with a single configuration line, rather than one line per file.

[domenic]

Yep, that's included :). See https://github.com/domenic/package-name-maps#basic-url-mapping

[dcleao]

It looks like the referenced anchor #basic-url-mapping no longer exists.

In any case, I think that the feature being requested by @bahrus is not supported by the current proposal, if I understood his request well. What I think @bahrus is asking for is support for bundle files which include several distinct modules... However, the ES6 module format does not support such thing as an inline modules, which would make it possible to ship several modules in a single file.

What import maps support is mapping several sub-modules of a package by mapping only a single base entry, as explained in packages via trailing slashes.

[domenic]

Ah, yes, packaging up multiple files into one file is not part of import maps. Instead, check out https://github.com/WICG/webpackage.