-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
à la carte vs buffet #56
Comments
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. |
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. |
Yep, that's included :). See https://github.com/domenic/package-name-maps#basic-url-mapping |
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. |
Ah, yes, packaging up multiple files into one file is not part of import maps. Instead, check out https://github.com/WICG/webpackage. |
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
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" }
The text was updated successfully, but these errors were encountered: