v3.1.0 - add the ability to import TS files directly

[abdulahmad307]

The plugins system was only able to load plugins via js files. A new feature was added that allows loading via ts files (#187). This PR is to release v3.1.0 (a minor bump because we're adding a new feature - does not break backwards compatability). Last version was 3.0.1.

[Copilot]

Pull request overview

This PR prepares the v3.1.1 release by extending the scanner’s plugin system to load TypeScript plugins (compiling them at runtime via esbuild), while also updating docs and bumping related dependencies/tooling.

Changes:

• Add runtime loading of index.ts plugins (with index.js fallback) in the find action plugin manager, plus supporting loaders/types and tests.
• Update documentation to reflect v3 usage and TypeScript plugin support.
• Refresh dependencies/toolchain across the repo and GitHub Actions, plus minor CI/workflow adjustments.

Show a summary per file

File	Description
.github/actions/find/src/pluginManager/index.ts	Refactors plugin manager into a module; loads TS first then JS; updates built-in plugin handling.
.github/actions/find/src/pluginManager/pluginFileLoaders.ts	Introduces TS/JS entry loaders (TS compiled via esbuild to a data: URL).
.github/actions/find/src/pluginManager/types.ts	Adds shared plugin type definitions.
.github/actions/find/src/dynamicImport.ts	Extends dynamic import helper to handle data: / file: URLs directly.
.github/actions/find/src/findForUrl.ts	Updates imports to new plugin manager module path.
.github/actions/find/tests/pluginManager.test.ts	Adds/updates unit tests for TS/JS plugin loading and duplicate handling.
.github/actions/find/tests/findForUrl.test.ts	Updates imports/types to match plugin manager refactor.
.github/actions/find/package.json / .github/actions/find/package-lock.json	Adds esbuild dependency and bumps Playwright + dev tooling.
.github/actions/*/tsconfig.json	Adds types: ["node"] for action TS builds.
.github/actions/*/package.json / package-lock.json	Bumps TS / Node typings versions for actions.
.github/scanner-plugins/reflow-scan/index.ts	Formatting adjustments.
.github/scanner-plugins/test-js-file-plugin-loading/index.js	Adds a JS plugin fixture intended for testing.
PLUGINS.md	Documents TS-first plugin loading behavior.
README.md	Updates usage example to v3 and documents open_grouped_issues.
.github/workflows/test.yml	Workflow tweaks; installs find dependencies explicitly.
sites/site-with-errors/Gemfile / Gemfile.lock	Bumps Puma to v8 for the test site.
package.json / package-lock.json	Updates repo-level dev tooling dependencies/lockfile.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Files not reviewed (4)

• .github/actions/auth/package-lock.json: Language not supported
• .github/actions/file/package-lock.json: Language not supported
• .github/actions/find/package-lock.json: Language not supported
• .github/actions/fix/package-lock.json: Language not supported

Comments suppressed due to low confidence (3)

.github/actions/find/src/pluginManager/index.ts:20

• plugins is exported as a mutable array, which allows external callers to mutate plugin manager state (and makes cache/ordering bugs harder to reason about). Since getPlugins() exists for tests, consider keeping plugins module-private and only exposing access via functions.
  .github/actions/find/src/pluginManager/index.ts:101
• The log message Skipping plugin without index.ts or index.js file is also used when index.ts exists but fails to compile/load (because the TS loader returns undefined on error). This can mislead users during debugging. Consider distinguishing "missing entry file" vs "failed to compile/load" (e.g., have the loader return a typed result/error, or track whether index.ts existed).
  .github/actions/find/src/pluginManager/index.ts:16
• BUILT_IN_PLUGINS includes test-js-file-plugin-load, which corresponds to a "test" plugin that is currently committed under .github/scanner-plugins/. Because built-in plugins are loaded from that directory, this will ship and load a test-only plugin in production runs. Move this fixture out of the built-in plugin directory (e.g., under tests/fixtures) and remove it from BUILT_IN_PLUGINS (or rename/rehome it if it is intended to be a real built-in plugin).

• Files reviewed: 21/28 changed files
• Comments generated: 5

[Copilot]

types.ts imports playwright as a runtime value, but it’s only used for typing (playwright.Page). This can accidentally become a real runtime dependency if TS compiler settings change, and it’s inconsistent with other files (e.g. generateScreenshots.ts) that use import type. Prefer import type {Page} from 'playwright' and reference Page in PluginDefaultParams.

Suggested change

	import playwright from 'playwright'
	export type PluginDefaultParams = {
	page: playwright.Page
	import type {Page} from 'playwright'
	export type PluginDefaultParams = {
	page: Page

[Copilot]

loadPluginViaTsFile swallows the build/import error (catch { ... }) and only logs a generic warning, which makes it hard to diagnose why a TypeScript plugin failed to load. Capture the error and include it in the warning (or rethrow) so users can fix their plugins based on actionable logs.

Suggested change

	} catch {
	core.warning(`Error loading plugin at path: ${pluginEntryPath}`)
	} catch (error) {
	const errorMessage = error instanceof Error ? error.message : String(error)
	core.warning(`Error loading plugin at path: ${pluginEntryPath}: ${errorMessage}`)

[Copilot]

This file appears to be a test-only fixture, but it lives under .github/scanner-plugins/ which is treated as the built-in plugin directory and will be packaged with the action. This can unintentionally ship a "test" plugin to users. Move it to a test fixture location and adjust tests to load it explicitly from there.

Suggested change

	export default async function TestJsFilePluginLoad({ page, addFinding } = {}) {
	console.log('testing plugin load using js file')
	}
	export const name = 'test-js-file-plugin-load'
	const isTestFixtureLoad =
	process.env.NODE_ENV === 'test' ||
	process.env.TEST_JS_FILE_PLUGIN_LOADING === 'true'
	export default async function TestJsFilePluginLoad({ page, addFinding } = {}) {
	console.log('testing plugin load using js file')
	}
	export const name = isTestFixtureLoad ? 'test-js-file-plugin-load' : undefined

[Copilot]

Typo in the comment: "this exist" → "this exists".

Suggested change

	// - this exist as a test to verify that loading plugins
	// - this exists as a test to verify that loading plugins

[Copilot]

This caching test is likely not asserting what it intends: loadPlugins() calls the module-local loadBuiltInPlugins()/loadCustomPlugins() bindings, so spying on pluginManager.loadBuiltInPlugins/pluginManager.loadCustomPlugins via vi.mock(..., { spy: true }) typically won’t record those internal calls. Consider asserting caching by checking observable effects instead (e.g., dynamicImport or fs.readdirSync call counts don’t increase on the second loadPlugins() call).

Suggested change

	await pluginManager.loadPlugins()
	expect(pluginManager.loadBuiltInPlugins).toHaveBeenCalledTimes(0)
	expect(pluginManager.loadCustomPlugins).toHaveBeenCalledTimes(0)
	const dynamicImportCallsAfterFirstLoad =
	vi.mocked(dynamicImportModule.dynamicImport).mock.calls.length
	const readdirSyncCallsAfterFirstLoad = vi.mocked(fs.readdirSync).mock.calls.length
	await pluginManager.loadPlugins()
	expect(dynamicImportModule.dynamicImport).toHaveBeenCalledTimes(
	dynamicImportCallsAfterFirstLoad,
	)
	expect(fs.readdirSync).toHaveBeenCalledTimes(readdirSyncCallsAfterFirstLoad)

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.