Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

package.json files that start with a UTF-8 BOM are rejected as invalid JSON

Geschlossen Anfängerfreundlich
  • Stimmt etwas nicht?
#14 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
82/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, node.js
Bereich
cli

Rechercherichtung

Lies lib/workspace.js, lib/package-managers.js und lib/config.js, beginnend mit den drei im Issue genannten Parsing-Stellen. Prüfe, wie ihre vorhandenen Tests das Parsen von JSON abdecken, und ergänze Fälle mit vorangestelltem BOM für getScripts(), detectPackageManager() und readWorkspaceConfig(). Fertig ist die Aufgabe, wenn jede Datei erfolgreich gelesen wird und das BOM ihre geparsten Werte nicht beeinflusst.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

bug
Description

A package.json that starts with a UTF-8 byte order mark (BOM) is rejected by the CLI, while npm reads it without complaint. Files like this are common on Windows: Windows PowerShell 5.1 writes a BOM with Set-Content -Encoding UTF8 or Out-File -Encoding utf8, and some editors add one.

For such a project, the CLI:

  • shows no scripts: opening the project shows Could not read package.json: Invalid JSON in … instead of the script list, although npm run <script> works in that folder;
  • would pick the wrong package manager: the packageManager field is read with the same JSON.parse, which fails silently, so a "packageManager": "[email protected]" project is detected as npm.

The CLI's own configuration file has the same problem: a config.json saved with a BOM, for example after editing it in an editor that adds one, is reported as Invalid configuration JSON.

Steps to reproduce

  1. Create a project whose package.json starts with a BOM.

    In a POSIX shell:

    mkdir -p /tmp/dws-bom/bom-app
printf '\357\273\277{"name":"bom-app","packageManager":"[email protected]","scripts":{"hello":"echo hello"}}' \
  > /tmp/dws-bom/bom-app/package.json

    In PowerShell 7, the same file can be written with Set-Content -Encoding utf8BOM; Windows PowerShell 5.1 adds the BOM with -Encoding UTF8.

  2. Check that npm accepts it:

    cd /tmp/dws-bom/bom-app && npm run hello

    This prints hello.

  3. Start the published CLI on the workspace, then open bom-app:

    DEV_WORKSPACE_CONFIG=/tmp/dws-bom/config.json \
  npx -p @modulane/[email protected] dws --workspace /tmp/dws-bom
Actual behaviour

The project screen shows the error from getScripts(). Observed on Windows, with the folder path shortened:

  Could not read package.json: Invalid JSON in …\bom-app\package.json: Unexpected token '', "{"name":""... is not valid JSON

Called directly on the same folder, detectPackageManager() returns { "name": "npm", "source": "default" } instead of pnpm from the packageManager field.

Expected behaviour

The BOM is ignored, as npm does: the script list shows hello, and the package manager line reads pnpm (from the packageManager field). A config.json with a BOM is read normally.

Cause

Three places pass the file content straight to JSON.parse, which rejects a leading U+FEFF:

Suggested fix
  1. Remove a single leading  before parsing, in all three places, for example with a small shared helper that reads and parses a JSON file. Only the start of the file is affected, so a BOM-like character inside a string value is kept.
  2. Add tests: getScripts(), detectPackageManager() and readWorkspaceConfig() each read a file that starts with a BOM.

I'm happy to open a PR for this.

Environment
  • @modulane/dev-workspace-cli 0.5.0 from npm. lib/ is identical on main at dfccb6b.
  • Node.js 22.13.1 and npm 10.9.2, Windows 11. The parsing code is the same on every platform.
Vorherrschende Sprache
JavaScript
Sterne
0
Forks
0
Ø Merge
43 Min.
Gemergte PRs (30 T.)
20

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modulane/dev-workspace-cli

Alle Issues in modulane/dev-workspace-cli

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.