Proposal: explicit named imports for non-JS/CSS assets

## Problem We currently allow you to do this: ```js import logo from './logo.png'; ``` After getting used to it, you’ll probably be comfortable with this giving you a URL. But what about other types? For example, what should this return? ```js import doc from './doc.md'; ``` Markdown source? Compiled HTML? An AST? What about this? ```js import Icon from './icon.svg'; ``` Should this give you a link? The SVG content? A React component? The usual answer is “decide it for yourself in the configuration file”. However, that doesn’t work for CRA so we decided to treat all unknown extensions as URL imports. This is not ideal because in some cases it just doesn’t make any sense, and in others there are advanced (but still relatively common) use cases that aren’t satisfied. ## Proposal What if we allowed to user to pick what they want, from a limited supported subset per filetype? ```js import { url as logoUrl } from './logo.png'; import { html as docHtml } from './doc.md'; import { ReactComponent as Icon } from './icon.svg'; ``` Named imports are checked by webpack so you’d get a compile error if you use an unsupported one. Things that are unused will be tree shaken so if you only use e.g. HTML of Markdown files, their source won’t be bundled. Same for SVGs (whether you consume them as raw source, URLs, or React components). Other zero-configuration tools can also adopt this approach. ## Concerns * What do we do with the default import? Ideally I’d like to forbid it

Posted by gaearon on Jan 9, 2018, 12:26 PM

Tags

• github (Other)

Related issues

• struct's lifetime requirements can be bypassed via covariant field assignment
• Proposal to Reorganize the Moderation Team and Review Moderation Policies
• Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
• proposal: container/...: generic collection types
• Better Custom Endpoint BYOK
• A concrete policy for backward compatibility until Godot 5.0