RFC-011 Supports data:text/javascript protocol

[hyf0]

• Feature Name: Supports data:text/javascript protocol
• Start Date: 2022-07-19
• RFC PR: WIP
• Issue: [Feature]: support import from dataurl protocol #456

Summary

Supports bundling code like'

import x from "data:text/javascript,export default 42"
console.log('x:',x);

Motivation

It seems in the spec, but I forgot which one.
It's one way to deal with virtual files.

Guide-level explanation

Let's say you have an idea that you want to inject some runtime code in bundling.

The idea requests you to deal with virtual modules.

virtual modules are javascript files that do not exist on the hard disks.

See the way how vite does it.

export default function myPlugin() {
  const virtualModuleId = 'virtual:my-module'
  const resolvedVirtualModuleId = '\0' + virtualModuleId

  return {
    name: 'my-plugin', // required, will show up in warnings and errors
    resolveId(id) {
      if (id === virtualModuleId) {
        return resolvedVirtualModuleId
      }
    },
    load(id) {
      if (id === resolvedVirtualModuleId) {
        return `export const msg = "from virtual module"`
      }
    }
  }
}

// foo.js

```ts
import { msg } from 'virtual:my-module'

You could see that vite intercepts the procedure of reading files from disk.

And that's the way using data:text/javascript protocol.

import { msg } from 'data:text/javascript,export const msg = "from virtual module"'

RSpack is ok to use Vite's way, but it has some problems. Such as the virtualModuleId will be exposed to other plugins. Since Vite's way is only a conversion not in the spec, people don't have a consistent solution, which could lead to some problems.

Reference-level explanation

• The implementation will be looks like Webpack, so you could see the part of the prior art first.

How to handle importing modules by relative paths in the data: protocol.

For example, attempting to load ./foo from data:text/javascript,import "./foo";

I tend to raise an error just like node.js did.

Drawbacks

It's in the spec, no significant reasons we shouldn't do it.

Rationale and alternatives

• Why is this design the best in the space of possible designs?

  It's in the spec.

• What other designs have been considered and what is the rationale for not choosing them?

  See the Motivation part.

Prior art

Webpack

• Webpack supports sheme and has a special hook resolveForScheme when resolving a module in NormalModuleFactory
• import { msg } from 'data:text/javascript,export const msg = "from virtual module"' will be parsed to two Dependencys.
  • HarmonyImportSideEffectDependency
  • HarmonyImportSpecifierDependency
    

• Webpack will try resolved to a NormalModule using the two Dpendencys(as a whole) in NormalModuleFactory#create
• Webpack will read the request property in HarmonyImportSideEffectDependency
• If a ModuleRequest has scheme, Webpack will call resolveForScheme hook and the DataURI plugin will use the hook to return the information of data:... to Webpack.
• In the end, we got a NormalModule.
• while NormalModule rendering, NormalModule will call readResource hook to get original source code.
• The DataURI plugin will use readResourceForScheme hook to provide source code.
  • readResourceForScheme hook is wrapper of readResource hook, which will be deprecated in Webpack 6.
• The rest of the process is just like normal imported module.

Related

• DataUriPlugin

Unresolved questions

Nope

Future possibilities

We should also supports data:text,html and data:text,css.

[hardfist]

some related discussion in webpack webpack/webpack#6437 (comment), it's the recommend way to deal virtual module in webpack, @sodatea and @antfu may have better ideas

[hardfist]

see

• https://nodejs.org/api/esm.html#data-imports,
• https://www.rfc-editor.org/rfc/rfc2397#section-2
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs

and actually data-url scheme is not only used in javascript but also used in html and css, it's the first class citizen, so we may need to handle it both in javascript、css and html

[byted-meow]

NodeJS's data protocol doesn't have a resolving context so relative specifiers like ./index.js will fail to resolve. Do we need to patch it to support relative specifiers?

[hyf0]

I tend to the way of nodejs.

[hyf0]

The RFC now is blocked by the unimplemented new architecture of RSpack.