Repository navigation
Auto-install the PostScript Language dependency and clarify why it's required - #23
Conversation
|
Thanks for approving the CI run — it caught a real gap in this PR, now fixed in d401161. The failure was legitimate: once
Verified locally on Windows from a clean |
|
Hi @DABH , you can rebase or merge in the latest changes in the default branch to fix the CI issues. |
The preview button is gated on 'resourceLangId == postscript' and the extension activates only 'onLanguage:postscript', but nothing in this extension registers the postscript language for .ps/.eps files - that comes from mxschmitt.postscript. Without it, .eps/.ps files open as plain text, so the preview button never appears and the extension never activates. The README listed the language extension only 'for syntax highlighting', which reads as optional. - package.json: add extensionDependencies so VS Code installs mxschmitt.postscript automatically with this extension - README: state the dependency is required for the preview button, and add a troubleshooting note for the no-button symptom
With extensionDependencies declared, the extension under test cannot
activate in the integration-test VS Code instance unless
mxschmitt.postscript is installed there, so the activation and command
tests fail ("Cannot activate ... depends on unknown extension").
Download the dependency as a VSIX and install it via the test CLI before
runTests. Installing by id instead can abort with "Signature
verification failed with 'ENOENT'" when the marketplace signature
verification tooling is unavailable in the test CLI; installing from a
local VSIX file avoids that path. spawnSync uses a shell on Windows
because Node refuses to spawn .cmd files directly (CVE-2024-27980).
Verified locally from a clean .vscode-test sandbox: 7 passing.
The existing CI combined Node 20-based actions with a legacy VS Code test harness. That harness did not install declared extension dependencies and its older Electron launcher no longer matched current macOS application layouts. The dependency tree also retained an abandoned runtime temp-file package and vulnerable transitive tooling. Move CI and release automation to Node 24-based actions, migrate tests to the VS Code test CLI, pin current release tools, and add weekly Dependabot updates. Refresh the supported development toolchain, replace shell command strings and the temp package with built-in process and filesystem APIs, preserve VS Code 1.46 compatibility through minimum-host type definitions, and bump the extension to 0.6.0. Mocha's patched diff and serialize-javascript releases are temporarily selected beyond upstream's declared ranges; both assertion failure rendering and the full extension suite were verified. Validation passed with a frozen install, compile, lint, actionlint, a zero-finding audit across 223 packages, 7 extension-host tests on VS Code 1.135, a VS Code 1.46 activation smoke test, automatic installation of the PR ahnafnafee#23 extension dependency, and a packaged 0.6.0 VSIX.
PR ahnafnafee#23 extends src/test/runTest.ts to install the PostScript language dependency before launching the extension host. Replacing that entry point with the VS Code test CLI in ahnafnafee#25 created a modify/delete conflict and bypassed the author's implementation. Restore the original runner byte-for-byte, make it the active test script again, and update only the separate Mocha suite loader for the current glob API and a stable startup timeout. Keep the current Electron launcher, add the narrow Node 24 fetch declaration needed by PR ahnafnafee#23's host-side installer, and remove the superseded test CLI dependency. Validation passed with a frozen install, compile, lint, a zero-finding audit across 190 packages, 7 extension-host tests, VSIX packaging, and a clean application check for the complete PR ahnafnafee#23 patch. README.md remains unchanged.
d401161 to
fcd476d
Compare
|
Rebased onto master ( The rebase resolved cleanly with no conflicts, and the two remaining failures were both fixed by your CI modernization rather than by anything in this PR:
One nice coincidence: Verified locally on the rebased branch from a clean Ready for another CI approval whenever you have a moment. |
2 participants
Problem
Installing this extension and following the Quick Start (Ghostscript + Poppler on PATH) is not enough to get a preview button. The button is contributed with
"when": "resourceLangId == postscript", and the extension activates only ononLanguage:postscript— but nothing in this extension registers thepostscriptlanguage for.ps/.epsfiles. That registration comes from the separate PostScript Language extension.Without it,
.eps/.psfiles open as Plain Text, so the preview icon never appears and the extension never activates. The README does list PostScript Language under Requirements, but frames it as being "for syntax highlighting", which reads as optional/cosmetic — so it's easy to skip and then conclude the extension is broken. (Hit this on a fresh Windows 11 setup with Ghostscript and Poppler correctly installed and on PATH; everything worked once the language extension was added.)Changes
"extensionDependencies": ["mxschmitt.postscript"]so VS Code installs the language extension automatically alongside this one — future users can't hit this failure mode.Alternative considered
If you'd rather not hard-depend on
mxschmitt.postscript, this extension could instead contribute a barelanguagesentry ({"id": "postscript", "extensions": [".ps", ".eps"]}). Language contributions merge across extensions, so mxschmitt's grammar would still apply when installed, but the preview button would work standalone. Happy to rework the PR that way if you prefer.Update: CI fix
The Unit Tests workflow initially failed on this PR — correctly so: with
extensionDependenciesdeclared, the extension can no longer activate in the integration-test VS Code instance, wheremxschmitt.postscriptis not installed (Cannot activate ... depends on unknown extension).src/test/runTest.tsnow downloads the dependency as a VSIX and installs it into the test instance beforerunTests(a VSIX file install also avoids theSignature verification failed with 'ENOENT'abort that id-based installs can hit in the test CLI). Verified locally from a clean.vscode-testsandbox on Windows: all 7 tests pass.