fix(cli): forward plugins and appPaths from config to createServer (#592)#593
Merged
Merged
Conversation
) loadConfig merges both keys from config.json, but the explicit createServer allowlist in bin/jss.js omitted them — so the documented 'declare the apps in config' route (#206/#589, docs/configuration.md) silently booted a server with no plugins, exactly the missing-app failure mode the loader was designed to refuse. Same for appPaths (#582). Verified: jss start -c config.json with a plugins entry now mounts the app (route responds, config delivered to activate); before the fix the same config booted with a 404 on the plugin route.
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
melvincarvalho
added a commit
that referenced
this pull request
Jul 11, 2026
The CLI config-file plugins block, first item remaining from #206 (#592, #593): bin/jss.js now forwards plugins and appPaths from the loaded config to createServer, so jss start -c config.json mounts the declared apps instead of silently booting without them. The documented 'declare the apps in config' route works from the CLI, and CLI drivers like servejss can now reach the plugin loader through a config file. No config auto-loading: plugins execute only from a file explicitly passed with -c. Remaining from #206: a repeatable --plugin CLI flag and a pluginDataDir override so served trees don't collect .plugins/ (both scoped in #592), #583 raw-body mode, #564 feature migration.
This was referenced Jul 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #592.
Problem
loadConfigmergesplugins(#589) andappPaths(#582) fromconfig.json, but the explicit allowlistbin/jss.jspasses tocreateServer(...)omitted both — so the documented config-file route ("declare the apps in config and the server imports, mounts, and tears them down itself") silently booted a server with no plugins and no error. That's exactly the silent-missing-app failure modesrc/plugins.jswas designed to refuse, and it left the #206 loader programmatic-only: nothing driving JSS through the CLI (including servejss) could mount plugins.Fix
Forward both keys in the
createServercall.createServeralready defaults each when undefined (Array.isArrayguards), so configs that don't set them are unaffected.Verified (A/B)
Config with
{"plugins": [{"module": "…/hello-plugin.mjs", "prefix": "/hello-app", "config": {"greeting": "hi"}}]}:jss start -c config.jsonmounts the app;GET /hello-app/hello→{"from":"plugin","config":{"greeting":"hi"}}Also confirmed a bad module path now fails the boot loudly through the CLI, as the loader intends.
Follow-ups from #592 (repeatable
--pluginCLI flag;pluginDataDiroverride so servejss-served trees don't collect.plugins/) left for separate PRs.