Don't break the build on incorrect static JS assets

[shalugin]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I'm using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

Something similar to #10460

Reproducible demo

No response

Steps to reproduce

This is simple to reproduce.

1. Create a fresh docusaurus site.
2. Create a file static/assets/upload/test.js:

{
  - / -sss;
}

2. Create a link in the documentation to this file

---
sidebar_position: 6
---

# Congratulations!

[Test](/assets/upload/test.js)

This will break a build (rspack also).
It looks like #10460.

If the ‘invalid’ JavaScript is in the folder, but there is no reference to it, everything will build correctly.

Expected behavior

Documentation is built even if there is a reference to an invalid JavaScript file in static assets.

Actual behavior

[ERROR] Client bundle compiled with errors therefore further build is impossible.
SyntaxError: /temp/docusaurus-rs-pack/my-website/static/assets/upload/test.js: Unterminated regular expression. (2:5)
  1 | {
> 2 |   - / -sss;
    |      ^
  3 | }
  4 |
    at parser.next (<anonymous>)
    at normalizeFile.next (<anonymous>)
    at run.next (<anonymous>)
    at transform.next (<anonymous>)

Your environment

docusaurus 3.7.0
node 20.17.0
npm 10.8.2

Self-service

• I'd be willing to fix this bug myself.

[Josh-Cena]

Hi, this is working as expected. The static folder doesn't mean "no bundling"; it just means it will be copied to the output folder. You can use pathname:// to opt out. See https://docusaurus.io/docs/markdown-features/assets#static-assets

[shalugin]

@Josh-Cena Thank you for pointing this out to me! I didn't notice that. Great!

[slorber]

Hi, this is working as expected.

Hmm, I'm not so sure in this case.

Markdown links referencing files are converted to require() calls, and by default require("./some.js") returns the transpiled module.

When it's used inside a Markdown links, returning the transpiled module has no utility at all IMHO, and we should probably use webpack file-loader in this case.

pathname:// is a decent workaround, but I still think we could improve a bit the default behavior for this edge case.

Note: this is unrelated to #10460