Navigation Menu

Skip to content

Instantly share code, notes, and snippets.

@Rich-Harris

Rich-Harris/README.md

Last active July 28, 2017 13:24
Show Gist options
  • Star 4 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Rich-Harris/4079c7cf46f4aa26c3e8df259b611294 to your computer and use it in GitHub Desktop.
Save Rich-Harris/4079c7cf46f4aa26c3e8df259b611294 to your computer and use it in GitHub Desktop.
Download ZIP
Bare imports in manifest
Raw
README.md

A hastily-written strawman for how bare imports could be resolved in browsers — see this convo.

Raw
index.html
<!doctype html>
<html>
<head>
<link rel='manifest' href='/manifest.json'>
<script type='module' src='./main.js'></script>
</head>
<body></body>
</html>
Raw
main.js
import _ from 'lodash'; // -> /vendor/lodash/index.js
import { linearScale } from 'd3-scale'; // -> /vendor/d3/d3-scale/index.js
import moment from 'moment'; // -> https://unpkg.com/moment -> https://unpkg.com/moment@2.18.1/moment.js
Raw
manifest.json
{
"name": "my-app",
"description": "a simple app",
"modules": {
"lodash": "/vendor/lodash/index.js",
"d3-*": "/vendor/d3/d3-$1/index.js",
"*": "https://unpkg.com/$1"
}
}
@rauschma
Copy link

This can be made to work with npm-installed node_modules, but what if modules there also make bare imports? Maybe the config needs to be done programmatically, at a package’s entry point?

@theefer
Copy link

theefer commented Jul 25, 2017

Unless I'm missing something: seems a shame to have to wait on an extra HTTP response to allow resolution of imports, should there be an syntax to inline within the HTML for performance reasons?

@Rich-Harris
Copy link
Author

@rauschma correct, you would also need entries for your dependencies' dependencies (which is no different from RequireJS configs of yore, of course). Using the wildcard syntax and pointing to a CDN like unpkg.com would fix that, as would only using libraries that are dependency-free (which includes a lot of the tools that are used in the front end world — React, D3, Three, jQuery etc), but you're right — the ideal situation is one where the manifest is generated by a build tool.

@theefer agree. not sure what that syntax would be. Mitigating factors: the manifest is typically small and one of the first things to get requested; it can be cached; and we can still get on with the task of fetching non-bare imports while we're waiting.

@meandmycode
Copy link

How does this interact with loader spec, I seem to remember that spec had stalled related to needing some major refactoring.

You'll have to forgive me if there's some prior discussion I'm missing here as there's been so much talk and so little progress on this topic, right now there's tools like rollup and webpack which amongst other things are baking in module resolution strategies, but there still seems to be little consensus.

For example, if I was to write a universal web app and use webpack then the bundled app has baked in all the resolutions (and transformations, i.e., how a request for sass would firstly resolve, and then transform), but doing the same thing node.js side would be a whole different system because the resolution and transformation system within webpack is not usable (or even standardized) on its own, nor designed with runtime performance in mind.

Ideally as a developer I want to define either imperatively or declaratively how transformation works (maybe even resolution, but I believe a sensible default resolution strategy should exist).

This way tools like rollup/webpack can focus on optimization of delivery of those assets without having to implement the resolution foundations.

The node.js guys obviously have a lot of history with this, the use module idea and mjs but are seemingly stalled on not being able to decide on a clear strategy forward.

I'd really love the js community, rollup, webpack, whatwg etc to work on abstracting and pushing a layer (module, spec, ???) that does this and proves a path forward for a standard, right now everyone has their own worlds and its hard to see a good result coming out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment