W-12345678: feat: make webapplication.json optional for sf webapp dev command#16
Conversation
deepu-mungamuri94
changed the title
This change makes the webapplication.json manifest file optional when running the `sf webapp dev` command. Webapps are now discovered by folder structure within the `webapplications/` directory. Key changes: - Webapp discovery now uses folder-based detection within webapplications/ folder - If webapplication.json exists, use manifest values; otherwise use defaults - Default dev command changed from 'npm run build' to 'npm run dev' - Auto-select webapp when running from inside a webapp folder - ManifestWatcher only enabled when webapplication.json is present - Improved error messages for missing dependencies (command not found) Code cleanup: - Remove unused ErrorHandler factory methods and inline single-use utilities - Remove dead code from ProxyServer (unused stats tracking) - Remove unused exported functions from webappDiscovery Testing & docs: - Add comprehensive unit tests for webappDiscovery (39 tests) - Update developer guide for optional manifest feature
deepu-mungamuri94
force-pushed
the
dev-command-optional-webappjson
branch
from
3ab5281 to
bcb2414
Compare
nrkruk
left a comment
nrkruk
left a comment
There was a problem hiding this comment.
Changes are fine, just need to address the comments. Can be done in follow up PR, just need to create a work item
| @@ -1,417 +0,0 @@ | |||
| /* | |||
There was a problem hiding this comment.
So error handler is no longer used now?
There was a problem hiding this comment.
Yeah, we don't need it. After refactoring, there are a couple of functions left & they were moved to the respective files and deleted this file.
| * @param dir - Directory to start from | ||
| * @returns Object with webapplications folder path and current webapp name, or null if not found | ||
| */ | ||
| function findWebapplicationsFolderUpward( |
There was a problem hiding this comment.
This recursive algorithm is way overkill. I think the 3 use cases are:
- We are running at the root of an SFDX project (i.e. there is an sfdx-project.json file).
-- The folder structure underneath will be well defined as to where the webapplications should be (<sfdxproject>/force-app/main/default/webapplications). We don't need to search for it, just check for its existence and assume each directory underneath is a webapplication (if they have a{webappname}.webapplication-meta.xml). The CLI should always prompt the user for which webapplication to run when --name is not specified (even if there is only a single webapplication) - We are running the command from the
<sfdxproject>/{...}/webapplications/<webapp>directory
-- In this case, we assume the user wants to run the dev server for the given web application. We can easily identify this is a web application by checking for the{webappname}.webapplication-meta.xmlor checking that the parent directory is namedwebapplications. If they supply other arguments to the command like --name and that is a different webapp from the current directory we are in, the CLI should error out. - [Optional] We are running the command from outside the context of an sfdx project / directory
-- Same as number 2, but we just check that there is a{webappname}.webapplication-meta.xmlfile in existence before starting the proxy server.
There was a problem hiding this comment.
Yeah, this makes sense. If we have the proper folder stucture, we can make it better.
I was unsure about this earlier : <sfdxproject>/force-app/main/default/webapplications and thought, the webapplications can reside anywhere as the sf webapp generate command is creating the webapp folder anywhere i wanted. It just asking for the parent folder to be webApplications.
I'll take care of this in next PR.
| @@ -80,10 +78,23 @@ export default class WebappDev extends SfCommand<WebAppDevResult> { | |||
| * Uses interactive arrow-key selection (standard SF CLI pattern) | |||
| */ | |||
There was a problem hiding this comment.
The algorithm here should be:
- Command is run WITHOUT
--nameor--url. We always prompt the user which web application to start (even if there is only 1). We then attempt to start the dev server for the webapp. - Command is run with
--name. We attempt to start the dev server for the webapp with that name and fail if it doesn't exist or we can't start the server. - Command is run with
--url. We check if the given url is already available. If it is, we skip starting the dev server and only start the proxy server. If it is not, we attempt to start the dev server with the given name (or prompt if no name given), and check that the given url matches the actual dev server url (throw a warning/error if this is not the case)
There was a problem hiding this comment.
yeah, some of it already handled partially. I'll take care of this in next PR.
Yeah, I'll take care of these in the next PR, along with the proxy detection from the vite-plugin. |
2 participants
WI: @W-21179372@
This change makes the webapplication.json manifest file optional when running the
sf webapp devcommand. Webapps are now discovered by folder structure within thewebapplications/directory.Key changes:
What does this PR do?
This removes the mandatory check for
webapplication.jsonfile forsf webapp devcommand. If not available, the command goes with default values by giving a warning message.What issues does this PR fix or reference?