Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add flag to accept location of config or routes.json #125

Closed
anthonychu opened this issue Mar 15, 2021 · 3 comments · Fixed by #149
Closed

Add flag to accept location of config or routes.json #125

anthonychu opened this issue Mar 15, 2021 · 3 comments · Fixed by #149
Assignees
Labels
scope: cli Issues happened a the ./src/cli level type: enhancement New feature or request

Comments

@anthonychu
Copy link
Member

When using a dev server (swa start http://localhost:3000) or when serving static files from a folder that doesn't contain staticwebapp.config.json (swa start ./dist), allow the location of the config/routes file to be specified from the CLI.

Should be able to specific the path to the file, or the folder containing the file (if both staticwebapp.config.json and routes.json exist, use staticwebapp.config.json).

We should also ensure the current behavior of how the files are found are properly documented.

@manekinekko
Copy link
Member

manekinekko commented Mar 15, 2021

Currently, the CLI looks for the staticwebapp.config.json or routes.json from the root of appLocation and crawls all folders to find those files. If both files are found, staticwebapp.config.json will be used.

Should we change this behavior @anthonychu ? The current algorithm can be found here: https://github.com/Azure/static-web-apps-cli/blob/main/src/core/utils.ts#L387-L433

@manekinekko manekinekko added scope: cli Issues happened a the ./src/cli level type: enhancement New feature or request labels Mar 15, 2021
@anthonychu
Copy link
Member Author

Yeah. Maybe I need to understand more about how the file discovery logic works. There’s no app_location if proxying to a dev server. I guess one can be inferred if we can find a GitHub action workflow. But I then would like to understand what happens if there are more than one workflow (like in a monorepo).

@manekinekko
Copy link
Member

Here is how we currently process the start command...

  • start cli with a context swa start <context>

  • if <appContext> is local folder and exists:

    • set appArtifactLocation = appContext
    • look for SWA workflow files under <appLocation>/.github/workflow/**.yml (use 1st file for the moment - see Support monorepos #32).
    • merge CLI config with workflow config (CLI takes precedence)
    • look for user's config custom rules under <appLocation> (staticwebapp.config.json or legacy routes.json).
    • run proxy and provide user's config
    • serve local static content
  • if <appContext> is HTTP dev server:

    • set appArtifactLocation = context
    • check if dev server is up and running.
    • skip workflow files and user's config custom rules.
    • run proxy
    • forward static content (not /.auth/ and not /api/) requests to app dev server
  • if --api=<apiContext> is provided:

    • set apiLocation = apiContext
    • if apiLocation is local folder and exists:
      • look for SWA workflow files under <appLocation>/.github/workflow/**.yml (use 1st file for the moment - see Support monorepos #32).
      • merge CLI config with workflow config (CLI takes precedence)
      • run func and serve /api/** queries
    • if apiLocation is HTTP dev server:
      • run proxy
      • forward /api/ to api dev server

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: cli Issues happened a the ./src/cli level type: enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants