Rich Harris Rich-Harris

Responding to this Twitter convo —

Let's say I'm building a blog post template page using from kind of front-end framework — for the sake of argument, we'll use Svelte. On this page, we'll have a share button that lets people share the blog post via Twitter.

Twitter makes this straightforward using their tweet web intent — just create an <a> tag with the appropriate href, and Twitter will take it from there. This is great — no need to faff around with an API.

But constructing the URL gets a bit unwieldy, so we'd like to turn it into a component:

<TwitterShare

In Node, you can do this:

const data = require('./data.json');

You can even do this (and Node will try various paths — ./data.js, ./data/index.js, ./data.json, ./data/index.json — until one matches):

const data = require('./data');

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

In answer to http://stackoverflow.com/questions/44034049/why-doesnt-rollup-js-treeshake-my-library/44036934?noredirect=1#comment75114138_44036934 — paste this code into https://rollupjs.org/repl

Most people treat these is interchangeable:

// named import
import { bar } from './foo.js';
bar();

// namespace import
import * as foo from './foo.js';
foo.bar();

Note: I'm not involved in Prepack in any way — please correct me if I say anything incorrect below!

A few people have asked me if Prepack and Svelte are similar projects with similar goals. The answer is 'no, they're not', but let's take a moment to explore why.

What is Prepack?

Prepack describes itself as a 'partial evaluator for JavaScript'. What that means is that it will run your code in a specialised interpreter that, rather than having some effect on the world (like printing a message to the console), will track the effects that would have happened and express them more directly.

So for example if you give it this code...

When Babel 6 came out, it was hard for a lot of packages to upgrade because it was essentially an entirely different category of thing than Babel 5. So what happened was that some packages upgraded, and some didn't — at least not straight away.

Some projects took the prima facie enlightened view that packages should expose untranspiled code, so that the consumers of that code could determine for themselves what needed to get transpiled based on the environments they supported.

That was a costly decision. If I was the author of an app that was using Babel 6, I couldn't import a library that was still using Babel 5 and shipping untranspiled code (because the configs were completely incompatible), and vice versa. Frankly, it was a bloody nuisance. We are bad at anticipating these sorts of issues. It will happen again at some point.

Adding a few extra bytes to pkg.main or pkg.module is a small price to pay for things just working. As well as avoiding the aforementioned headaches, it means that your

Following this convo:

Your browser requests https://unpkg.com/foo:

<script type='module' src='https://unpkg.com/foo'></script>

unpkg responds with the contents of foo...