Bump globals from 17.5.0 to 17.6.0

[dependabot]

Bumps globals from 17.5.0 to 17.6.0.

Release notes

Sourced from globals's releases.

v17.6.0

• Update globals (2026-05-01) (#343) 00a4dd9

---

sindresorhus/globals@v17.5.0...v17.6.0

Commits

• 6b15870 17.6.0
• 00a4dd9 Update globals (2026-05-01) (#343)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[fossabot]

[fossabot]

✓ Safe to upgrade

I recommend merging this upgrade because the changes are purely additive — the upgrade only adds new WebXR-related browser globals (e.g., XRCompositionLayer, XRPlane, XRLayerEvent) to the globals.browser set, along with a minor internal puppeteer dev dependency bump. The codebase uses globals exclusively in eslint.config.mjs as a dev-only ESLint configuration tool, accessing globals.node, globals.mocha, and globals.browser. The globals.browser usage pattern at line 39 spreads all browser globals as "off" entries — this pattern naturally and safely accommodates any newly added browser globals without requiring code changes. The globals.node and globals.mocha sets, which directly influence linting behavior, are unchanged. The two CI failures detected are both clearly attributable to a pre-existing shell-escaping bug in the FOSSA action's JSON output processing and a misconfigured debug artifact upload path — neither issue has any connection to the globals package upgrade.

Fix Suggestions

We identified 2 fixable issues in this upgrade.

• Fix the shell-escaping bug in the FOSSA action's report processing: the action's internal code interpolates raw JSON output from fossa report attribution --format json into a bash script without proper quoting. The JSON contains parentheses (e.g., in license names like 'MIT (X11)') which bash interprets as command substitution. The fix requires modifying the action's source code (likely in src/ TypeScript files) to either: (1) write the JSON to a temporary file and read it back, (2) use printf '%s' with proper escaping, or (3) use the multi-line heredoc syntax for $GITHUB_OUTPUT (e.g., echo 'report<<EOF' >> $GITHUB_OUTPUT). Search the action's source for where the attribution report output is set as a step output or echoed in a shell context — look for patterns like core.exportVariable, core.setOutput, or template literals that embed the JSON string into shell commands.
  Files: src/run-fossa.ts, action.yml
• Fix the FOSSA debug artifact upload path: the actions/upload-artifact step expects ./fossa.debug.json.gz but the FOSSA CLI 3.17.3 may write the debug file to a different location. Steps to resolve: (1) Run fossa analyze --debug locally or in a test workflow and observe the actual output path of the debug file (it may be in a subdirectory or have a different filename). (2) Search the action source and workflow YAML files for the string fossa.debug.json.gz to find where this path is configured. (3) Update the path: field in the actions/upload-artifact step to match the actual debug output location. Alternatively, add a find . -name '*.debug*' -o -name 'fossa.debug*' step before the upload to discover where the file is actually written.
  Files: action.yml, .github/workflows/build.yaml

AI Assistant Prompt

Copy prompt for AI assistant

# Fix Pre-existing CI Failures in fossa-action (PR #300)

I'm upgrading the `globals` package in the `fossa-action` repository. The upgrade itself is safe (only adds new WebXR browser globals), but CI reveals two **pre-existing bugs** unrelated to the upgrade that need fixing.

## Context
- The `globals` package is used only in `eslint.config.mjs` for ESLint configuration
- The upgrade adds WebXR-related browser globals — no breaking changes
- Two CI failures in the `fossa-scan` job need to be fixed independently

---

## Bug 1: Shell-escaping bug in FOSSA report processing (CRITICAL)

**Symptom:** Fatal bash `syntax error near unexpected token '('` (exit code 2) during CI.

**Root cause:** The action embeds raw JSON output from `fossa report attribution --format json` directly into a shell script without proper escaping. The JSON contains parentheses in license names (e.g., `MIT (X11)`) which bash interprets as command substitution syntax.

**Files to investigate:**
- `src/run-fossa.ts` (primary — look for where attribution report output is captured and set as output/env var)
- `action.yml` (check shell script steps that handle report output)

**What to look for:**
- Patterns like `core.exportVariable()`, `core.setOutput()`, or template literals that embed JSON into shell commands
- Any place where the output of `fossa report attribution --format json` is interpolated into a bash context

**Fix approaches (pick one):**
1. **Heredoc syntax for `$GITHUB_OUTPUT`** (preferred):
   ```bash
   echo 'report<<EOF' >> $GITHUB_OUTPUT
   echo "$json_content" >> $GITHUB_OUTPUT
   echo 'EOF' >> $GITHUB_OUTPUT
   ```
2. **Write JSON to a temp file** instead of passing through shell variables
3. **Use `printf '%s'`** with proper quoting to avoid shell interpretation

Make sure any fix handles arbitrary JSON content safely, including parentheses, single quotes, double quotes, backticks, and dollar signs.

---

## Bug 2: FOSSA debug artifact upload path mismatch (NON-FATAL)

**Symptom:** Warning that `./fossa.debug.json.gz` was not found during `actions/upload-artifact` step.

**Root cause:** The `actions/upload-artifact` step expects `./fossa.debug.json.gz` but FOSSA CLI 3.17.3 may write the debug file to a different location or filename.

**Files to investigate:**
- `action.yml` (look for the `upload-artifact` step and its `path:` field)
- `.github/workflows/build.yaml` (check for artifact upload configuration)

**Fix approach:**
1. Search for all references to `fossa.debug.json.gz` in the codebase
2. Add a diagnostic step before the upload to find the actual debug file:
   ```bash
   find . -name '*.debug*' -o -name 'fossa.debug*' 2>/dev/null
   ```
3. Update the `path:` field in the `actions/upload-artifact` step to match the actual output location
4. Consider using a glob pattern like `**/fossa.debug*` for resilience across CLI versions

---

## Instructions
1. Fix Bug 1 first — it causes a hard CI failure
2. Fix Bug 2 second — it's a non-fatal warning but should be corrected
3. Neither fix is related to the `globals` upgrade; they are pre-existing issues
4. Do not modify `eslint.config.mjs` or the `globals` dependency — those are fine as-is
5. Test that the shell-escaping fix handles JSON with special characters like `MIT (X11)` license names

What we checked

• The globals package is declared as a devDependency at ^17.6.0, confirming it has no presence in production runtime code. ^[1]
• globals is imported only in the ESLint flat-config file, confirming the package's scope is limited to developer tooling. ^[2]
• globals.browser is spread via Object.fromEntries(Object.entries(globals.browser).map(([key]) => [key, "off"])) — this pattern dynamically maps all browser globals to "off", so any newly added WebXR globals (e.g., XRCompositionLayer, XRPlane) are automatically handled without any code changes. ^[3]
• globals.node is spread directly into the ESLint globals config; the upgrade does not modify the Node.js globals set, so linting behavior for Node.js source files is unaffected. ^[4]
• globals.mocha is spread directly into the ESLint globals config; the upgrade does not modify the Mocha globals set, so test file linting behavior is unaffected. ^[5]
• No application source files import globals — its usage is confined entirely to this single ESLint configuration file, meaning zero risk of runtime regressions from this upgrade. ^[6]

Dependency Usage

The globals package is used exclusively within the project's developer tooling layer, specifically in eslint.config.mjs, where it supplies predefined environment-aware global variable sets — globals.node, globals.mocha, and globals.browser — to configure ESLint's linting rules correctly for a Node.js/Mocha testing context. This dependency has no footprint in application source code and solely supports code quality enforcement during development and CI workflows. Its usage reflects a standard ESLint flat-config pattern, ensuring linting accurately reflects the runtime environment without flagging legitimate globals as undefined variables.

• globals is imported only in the ESLint flat-config file, confirming the package's scope is limited to developer tooling.
  eslint.config.mjs:6
• globals.browser is spread via Object.fromEntries(Object.entries(globals.browser).map(([key]) => [key, "off"])) — this pattern dynamically maps all browser globals to "off", so any newly added WebXR globals (e.g., XRCompositionLayer, XRPlane) are automatically handled without any code changes.
  eslint.config.mjs:39

View 3 more usages

• globals.node is spread directly into the ESLint globals config; the upgrade does not modify the Node.js globals set, so linting behavior for Node.js source files is unaffected.
  eslint.config.mjs:40
• globals.mocha is spread directly into the ESLint globals config; the upgrade does not modify the Mocha globals set, so test file linting behavior is unaffected.
  eslint.config.mjs:41
• No application source files import globals — its usage is confined entirely to this single ESLint configuration file, meaning zero risk of runtime regressions from this upgrade.
  eslint.config.mjs

Changes

The globals package update adds ten new WebXR browser globals, including XRCompositionLayer, XRPlane, XRProjectionLayer, and related layer/event types, expanding linting environment support for WebXR Layer API surfaces. No security fixes or breaking changes are included.

• Update globals (2026-05-01) (#343) 00a4dd9 (v17.5.0-17.6.0, release notes)
• Added XRCompositionLayer to browser globals - new WebXR API for composition layers (v17.6.0, package source)
• Added XRCubeLayer to browser globals - new WebXR API for cube layer rendering (v17.6.0, package source)

View 9 more changes

• Added XRCylinderLayer to browser globals - new WebXR API for cylindrical layer rendering (v17.6.0, package source)
• Added XREquirectLayer to browser globals - new WebXR API for equirectangular layer rendering (v17.6.0, package source)
• Added XRLayerEvent to browser globals - new WebXR event type for layer events (v17.6.0, package source)
• Added XRPlane to browser globals - new WebXR API for plane detection (v17.6.0, package source)
• Added XRPlaneSet to browser globals - new WebXR API collection type for planes (v17.6.0, package source)
• Added XRProjectionLayer to browser globals - new WebXR API for projection layer rendering (v17.6.0, package source)
• Added XRQuadLayer to browser globals - new WebXR API for quad layer rendering (v17.6.0, package source)
• Added XRSubImage to browser globals - new WebXR API for sub-image management (v17.6.0, package source)
• Updated puppeteer dev dependency from ^24.40.0 to ^24.42.0 for improved browser automation (v17.6.0, package source)

References (6)

[1]: The globals package is declared as a devDependency at ^17.6.0, confirming it has no presence in production runtime code.

fossa-action/package.json

Line 36 in 7cf2b8d

"globals": "^17.6.0",

[2]: globals is imported only in the ESLint flat-config file, confirming the package's scope is limited to developer tooling.

fossa-action/eslint.config.mjs

Line 6 in 7cf2b8d

import globals from "globals";

[3]: globals.browser is spread via Object.fromEntries(Object.entries(globals.browser).map(([key]) => [key, "off"])) — this pattern dynamically maps all browser globals to "off", so any newly added WebXR globals (e.g., XRCompositionLayer, XRPlane) are automatically handled without any code changes.

fossa-action/eslint.config.mjs

Line 39 in 7cf2b8d

...Object.fromEntries(Object.entries(globals.browser).map(([key]) => [key, "off"])),

[4]: globals.node is spread directly into the ESLint globals config; the upgrade does not modify the Node.js globals set, so linting behavior for Node.js source files is unaffected.

fossa-action/eslint.config.mjs

Line 40 in 7cf2b8d

...globals.node,

[5]: globals.mocha is spread directly into the ESLint globals config; the upgrade does not modify the Mocha globals set, so test file linting behavior is unaffected.

fossa-action/eslint.config.mjs

Line 41 in 7cf2b8d

...globals.mocha,

[6]: No application source files import globals — its usage is confined entirely to this single ESLint configuration file, meaning zero risk of runtime regressions from this upgrade.
https://github.com/fossas/fossa-action/blob/7cf2b8d655feb0810951b0c29f3056f4875bceec/eslint.config.mjs

---

fossabot analyzed this PR using static analysis and dependency research. View this analysis on the web