A hastily-written strawman for how bare imports could be resolved in browsers — see this convo.
Last active
July 28, 2017 13:24
-
-
Save Rich-Harris/4079c7cf46f4aa26c3e8df259b611294 to your computer and use it in GitHub Desktop.
Bare imports in manifest
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
<!doctype html> | |
<html> | |
<head> | |
<link rel='manifest' href='/manifest.json'> | |
<script type='module' src='./main.js'></script> | |
</head> | |
<body></body> | |
</html> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
{ | |
"name": "my-app", | |
"description": "a simple app", | |
"modules": { | |
"lodash": "/vendor/lodash/index.js", | |
"d3-*": "/vendor/d3/d3-$1/index.js", | |
"*": "https://unpkg.com/$1" | |
} | |
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.