web-infra-dev / web-infra-dev/rslib

[Feature]: resolve new URL as entry

Open
#1,825 0 comments 1 reaction 1 assignee View on GitHub

@elecmonkey is already working on this.

Since Sep 4, 2026.

Rspack
Dominant language
TypeScript
Stars
1k
Forks
67
Avg merge
6h 9m
Merged PRs (30d)
57

Description

What problem does this feature solve?

After #1774, which closes #929, Rslib can compile a worker entry when new URL() is used directly inside a statically analyzable Web Worker constructor:

new Worker(new URL('./worker.ts', import.meta.url));

However, worker-pool libraries usually receive the worker module through an option instead of constructing a Web Worker directly.

For example, Tinypool's documented API uses a filename option:

import Tinypool from 'tinypool';

const pool = new Tinypool({
  filename: new URL('./renderPageWorker.ts', import.meta.url).href,
});

The referenced source file is src/renderPageWorker.ts, but the URL is not recognized as a module entry.

According to the Rslib static assets documentation, JavaScript and TypeScript files referenced by a plain new URL() are currently treated as URL assets. They bypass the built-in loaders and their original contents are emitted as assets.

As a result, the worker may be emitted as uncompiled TypeScript instead of an executable ESM module.

The current workaround is to manually declare every worker module as an additional entry:

import { defineConfig } from '@rslib/core';

export default defineConfig({
  source: {
    entry: {
      index: './src/index.ts',
      renderPageWorker: './src/renderPageWorker.ts',
    },
  },
});

The application code must then reference the expected output filename:

const pool = new Tinypool({
  filename: new URL('./renderPageWorker.js', import.meta.url).href,
});

This duplicates the worker relationship in the configuration, couples source code to the output layout, and becomes inconvenient when a library has multiple dynamically referenced entry modules.

The same requirement exists for Piscina, child_process.fork(), custom worker pools, and other APIs that accept the URL or filename of an executable module.

What does the proposed API look like?

Rslib should treat a JavaScript or TypeScript module referenced by new URL() as a module entry and rewrite the URL to its compiled output.

For example:

import Tinypool from 'tinypool';

export const pool = new Tinypool({
  filename: new URL('./renderPageWorker.ts', import.meta.url).href,
});
export default async function renderPage(pathname: string): Promise<string> {
  return `<html><body>${pathname}</body></html>`;
}

Expected output:

dist/
├── index.js
└── renderPageWorker.js
import Tinypool from 'tinypool';

const pool = new Tinypool({
  filename: new URL('./renderPageWorker.js', import.meta.url).href,
});

export { pool };
async function renderPage(pathname) {
  return `<html><body>${pathname}</body></html>`;
}

export { renderPage as default };

Expected semantics:

  • Resolve the referenced module using Rslib's normal resolver.
  • Compile the referenced file as an independent ESM entry instead of emitting its original source as a URL asset.
  • Rewrite the .ts URL to the corresponding .js output file.
  • In bundle mode, bundle the entry's dependencies into its output graph.
  • In bundleless mode, compile the entry and preserve its module structure.
  • Keep ordinary new URL('./asset', import.meta.url) behavior unchanged.
  • Avoid adding a Webpack/Rspack runtime when the generated entry does not require one.

The important requirement is that statically analyzable JavaScript and TypeScript modules referenced by new URL() can be compiled as entries without also declaring them in source.entry.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.