static-web-apps-cli: Failed to load staticwebapp.config.json schema on start

Hi all, the fix has been merged in PR #808. In summary, we added a logic to load static-web-apps-cli/schema/staticwebapp.config.json as a backup, in case https://json.schemastore.org/staticwebapp.config.json get timeout again.

Before a new version of swa-cli is released, you can feel free to download and test it from GitHub. Here are the steps:

1. git clone https://github.com/Azure/static-web-apps-cli.git
2. cd into the folder “static-web-apps-cli”
3. run “npm install”, then “npm run build”
4. run “npm link ./”, which allows you to use this version of swa-cli globally.
5. * if you want to update the version of swa-cli, just delete this local folder “static-web-apps-cli” and run “npm install -g @azure/static-web-apps-cli” to reinstall the official version.

Thanks a lot for checking if this update works for you.

The solution shouldn’t be reliant upon any specific host, MS controlled or otherwise. Its a dependency that can cause the current pain points many of us are receiving.

Why not ship a fallback schema with the tool, kept up to date with each update.

Better yet, don’t perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn’t be any hard-coded dependency on a remote server being available.

Here’s a simple fix that skips the validation (as the message says) instead of killing process. Some reordering of rows and missing schema returns config instead of null. File: node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js

async function validateRuntimeConfigAndGetData(filepath) {
    const ajv4 = new ajv_draft_04_1.default({
        strict: false,
        allErrors: true,
    });    
    logger_1.logger.silly(`Reading content from staticwebapp.config.json...`);
    const content = (await readFile(filepath)).toString("utf-8");
    let config;
    try {
        logger_1.logger.silly(`Parsing staticwebapp.config.json...`);
        config = JSON.parse(content);
    }
    catch (err) {
        printJSONValidationWarnings(filepath, content, err.message);
        return null;
    }
    logger_1.logger.silly(`Loading staticwebapp.config.json schema...`);
    const schema = await loadSWAConfigSchema();
    if (!schema) {
        logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`);
        return config;
    }
    logger_1.logger.silly(`Compiling schema...`);
    const validate = ajv4.compile(schema);
    logger_1.logger.silly(`Validating staticwebapp.config.json...`);
    const isValidSWAConfigFile = validate(config);
    if (!isValidSWAConfigFile) {
        printSchemaValidationWarnings(filepath, config, validate);
        return null;
    }
    logger_1.logger.silly(`File validated successfully. Continuing with configuration!`);
    return config;
}

Temporary solution (what I did):

1. Go to %userprofile%\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\core\utils (for Windows).
2. Open user-config.js.
3. Search for https://json.schemastore.org/staticwebapp.config.json.
4. Upload staticwebapp.config.json to blob storage (for example) or use my file: https://stcuberdonintegration.blob.core.windows.net/assets/staticwebapp.config.json (Will be removed in 24H)
5. Replace https://json.schemastore.org/staticwebapp.config.json with your remote path.

Can we skip accessing the network for the commands that does not require it? I am often find myself working on the plane with unstable internet connection. I don’t understand why do I need to download anything from the Internet if I just want to test the app. For deployment we may have additional arguments.

Thanks for the feedback. It’s an intermittent bug but occurs more common recently. We are going to have a local backup schema as a fallback option if the download fails. The fix will come soon.

@cjk7989 this should really be reopened, https://json.schemastore.org being down caused a monorepo with hundreds of devs to block all pull requests. We should be able to provide a local fallback.

Good morning. Can’t locally start my Azure static web app because … network timeout at: https://json.schemastore.org/staticwebapp.config.json

The schema store is just sending 429 and 503s

I agree that this is a weird network dependency on what should should be “Airplane mode” type local dev work.

It’s happening, right now… AGAIN!!!

Please, reopen and FIX this.

I followed @LiamOSullivan steps above but rather than putting in a new blob address I increased the time out

• Go to %userprofile%\AppData\Roaming\npm\node_modules@azure\static-web-apps-cli\dist\core\utils (for Windows).
• Open user-config.js.
• Search for https://json.schemastore.org/staticwebapp.config.json.
• Two line below increase the time out to 10000 milliseconds
• Save and retry

Hi all, we have published swa-cli@v1.1.5, which will throw an error if staticwebapp.config.json schema is failed to be download. And we plan to design a fallback method to completely fix the issue in the next version. Thanks very much for your feedback and suggestions.

…

That is not correct @nathanblair, the GitHub action doesn’t rely on the CLI at all, which is why that is the preferred way for production deployments. The GitHub action is just a wrapper around the SWA container (mcr.microsoft.com/appsvc/staticappsclient:stable) and you can currently use the SWA container as well as the GitHub action without problems. There is no production tooling around SWA relying on the CLI, as the SWA CLI is mainly for local development.

Not everyone has ability to use the GitHub Action for their deployment and should not be required to do so. Again, the underlying tool should be open sourced to begin with

That is what the container image mcr.microsoft.com/appsvc/staticappsclient:stable is for 😉 This is not the right place to request a certain tool to be open sourced. If you want to request other tools for the deployment or something to be open sourced, you could open a separate issue for that.

The important part is that the SWA CLI should not be part of production release tooling and that the tools for that are the container image and the GitHub action. There is currently no dependency on the CLI for production deployments.

The solution shouldn’t be reliant upon any specific host, MS controlled or otherwise. Its a dependency that can cause the current pain points many of us are receiving.

Why not ship a fallback schema with the tool, kept up to date with each update.

I think this is the proposal that should be given the most preferential treatment.

Really? Is it fixed so that when the schemastore isn’t available it at least throws some kind of error and does not deploy a not working swa?.. I think it is not fixed.

Solved with workaround!!

After few hrs of struggle and understand I finally got it work by storing schema to different host and pointing updating the same in user-config.js. Thanks @cjk7989

Note: For mac os, path for file is: /usr/local/lib/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js. depends on node installation directory. change the schemaUrl in the file to your hosted schema path.

Those who need the content of the schema to host, I have a copy of it at: https://anuraggandhi.com/schema-swa.config.json. (please don’t use it directly from this host. It will be removed shortly.)

Better yet, don’t perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn’t be any hard-coded dependency on a remote server being available.

I wouldn’t use the CLI for production deployments anyway, it’s mainly made for local development and validation. You should use the GitHub action directly, as the CLI deploy command is missing a lot of configuration features for deployment like customizing data-api path’s etc. and the GitHub action doesn’t rely on the CLI. You could even directly use the deployment container image or the StaticSitesClient directly for deployment (probably unsupported), to not be dependent on the CLI for production. Besides that, I 100% agree that there should never be a dependency on a remote server for any local development tooling.

All of the other options rely on this under the hood. So doing anything that doesn’t rely on this isn’t an option. The real tool, the StaticClientSites binary, is kept closed source. Otherwise I’d just modify and build that directly myself and use it. This CLI tool and any other cli tool that publishes to Azure Static Sites use that closed-source binary because it’s the only way to get resources to Azure Static Sites.

That is not correct @nathanblair, the GitHub action doesn’t rely on the CLI at all, which is why that is the preferred way for production deployments. The GitHub action is just a wrapper around the SWA container (mcr.microsoft.com/appsvc/staticappsclient:stable) and you can currently use the SWA container as well as the GitHub action without problems. There is no production tooling around SWA relying on the CLI, as the SWA CLI is mainly for local development.

A quick way to use the CLI until this is resolved is to remove the “true” parameter to the logger.error method, as this causes the script to exit:

static-web-apps-cli/src/core/utils/user-config.ts

This: logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`); instead of this: logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`, true);

Credit to @cristianbretti

Removing the “true” from logger_1.logger.error to skip validation will cause the routing to not work. I recommend the two temporary solutions mentioned by @zainzafar90, to save the schema into Azure blob storage, or set the timeout to a larger value.

I probably understood this problem. In loadSWAConfigSchema(), there is a process to load data from the following SchemaURL, right?

const schemaUrl = "https://json.schemastore.org/staticwebapp.config.json";

Currently, it seems that the data delivery for this URL is very slow. This is causing a timeout.

I agree with @avalor1 . We should not depend on a third-party service which can become unavailable without notice.

Edit: My understanding is that the purpose of https://json.schemastore.org/ is to be used by various IDEs and VSCode extensions and SWA-CLI is using it for essential functionalities (build and deploy); even then it just logs a warning if it’s unavailable. At the very least, on deployment it should throw an error when the service is unavailable. This way we’ll avoid having broken SWAs in production. (and again wait for the service to become available 🙃)

I can confirm that issue as well on 1.1.4. Also, the fix posted by @aresofficial is working for me.

That’s really strange, how Azure position Static Web Apps as production-ready service, where your app can be totally inaccessible because of downtime on 3rd party service. Moreover, not a single failure was seen, swa deploy will silently deploy your app and destroy all routes. That’s “amazing”

Seeing the same problem. This does also affect the swa deploy command leading to a not working SWA

I’m also running into this issue. Just had a new deployment, and users are redirected to 404 page if they try to access links directly or refresh the page.

Close it as swa-cli@v1.1.7 has been released and fixed this issue, thanks very much for all your feedback and suggestions.

I followed these instructions from cjk7989. This installs 1.17-alpha ,which solved the problem for me.

Hi all, the fix has been merged in PR #808. In sumarry, we added a logic to load static-web-apps-cli/schema/staticwebapp.config.json as a backup, in case https://json.schemastore.org/staticwebapp.config.json get timeout again.

Before a new version of swa-cli is released, you can feel free to download and test it from GitHub. Here are the steps:

1. git clone https://github.com/Azure/static-web-apps-cli.git
2. cd into the folder “static-web-apps-cli”
3. run “npm install”, then “npm run build”
4. run “npm link ./”, which allows you to use this version of swa-cli globally.
5. • if you want to update the version of swa-cli, just delete this local folder “static-web-apps-cli” and run “npm install -g @azure/static-web-apps-cli” to reinstall the official version.

Thanks a lot for checking if this update works for you.

Hello,

I still have problem to deploy my application through Azure DevOps. Here is the output :

Deploying to environment: production

network timeout at: https://json.schemastore.org/staticwebapp.config.json
✖ Failed to load staticwebapp.config.json schema. Continuing without validation!
##[debug]Exit code 1 received from tool 'C:\Program Files\Git\bin\bash.exe'
##[debug]STDIO streams have closed for tool 'C:\Program Files\Git\bin\bash.exe'
##[debug]task result: Failed
##[error]Script failed with exit code: 1
##[debug]Processed: ##vso[task.issue type=error;]Script failed with exit code: 1
##[debug]Processed: ##vso[task.complete result=Failed;]Script failed with exit code: 1

Even if it says that it would “Continuing without validation!”, the deployment still fail. It seems that https://json.schemastore.org/staticwebapp.config.json still have a timeout.

How can I manage to avoid that validation ? Do I need to deploy throught Azure CLI, would it help ? Maybe I could use a script in my deploy.yml template, but not sure how to do it…

Thanks for your help !

For SWA deployment in a Azure DevOps CI/CD pipeline, the recommended way is to use the “AzureStaticWebApp” task (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/azure-static-web-app-v0?view=azure-pipelines). The CLI is mainly for local development not for production deployments. The same action exists for Github, Gitlab and Bitbucket and as container for other deployment systems.

All builds fall down because of this issue

I understand, I also have the same set of frustration as my deployment delayed by many hrs due to this. Hope MS will fix it intelligently and will not rely on 3rd party sites for their production ready tools.

Better solution, i think: MS should host the schemas themselves to a relied host and use them for their tools. They should take care of updating the schema when needed.

Temporary solution (what I did):

1. Go to %userprofile%\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\core\utils (for Windows).
2. Open user-config.js.
3. Search for https://json.schemastore.org/staticwebapp.config.json.
4. Upload staticwebapp.config.json to blob storage (for example) or use my file: https://stcuberdonintegration.blob.core.windows.net/assets/staticwebapp.config.json (Will be removed in 24H)
5. Replace https://json.schemastore.org/staticwebapp.config.json with your remote path.

Thank you. I have found another way to solve it. And it works without hosting the staticwebapp.config.json file So instead of simply replacing the URL, I increased the timeout to 5 minutes instead of just 10 seconds, as the only issue was I was able to load the file in browser but it would take more than 10 seconds.

Here’s how you can do it:

1. Go to user-config.js
2. Find const schemaUrl = "https://json.schemastore.org/staticwebapp.config.json"; and below there’s a line with timeout set to 10 * 1000
3. Change the 10 to whatever number you think works
4. Reload your terminal (it wasn’t working without it)

PS. Finding user-config was tricky because it was installed globally and since I am using nvm mine was located at ~/.nvm/versions/node/v18.18.0/lib/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js

Here’s a simple fix that skips the validation (as the message says) instead of killing process. Some reordering of rows and missing schema returns config instead of null. File: node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js

async function validateRuntimeConfigAndGetData(filepath) {
    const ajv4 = new ajv_draft_04_1.default({
        strict: false,
        allErrors: true,
    });    
    logger_1.logger.silly(`Reading content from staticwebapp.config.json...`);
    const content = (await readFile(filepath)).toString("utf-8");
    let config;
    try {
        logger_1.logger.silly(`Parsing staticwebapp.config.json...`);
        config = JSON.parse(content);
    }
    catch (err) {
        printJSONValidationWarnings(filepath, content, err.message);
        return null;
    }
    logger_1.logger.silly(`Loading staticwebapp.config.json schema...`);
    const schema = await loadSWAConfigSchema();
    if (!schema) {
        logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`);
        return config;
    }
    logger_1.logger.silly(`Compiling schema...`);
    const validate = ajv4.compile(schema);
    logger_1.logger.silly(`Validating staticwebapp.config.json...`);
    const isValidSWAConfigFile = validate(config);
    if (!isValidSWAConfigFile) {
        printSchemaValidationWarnings(filepath, config, validate);
        return null;
    }
    logger_1.logger.silly(`File validated successfully. Continuing with configuration!`);
    return config;
}

Saved my teams morning productivity, thank you!

Currently swa fails to start locally because of this error:

 network timeout at: https://json.schemastore.org/staticwebapp.config.json
[swa] ✖ Failed to load staticwebapp.config.json schema. Continuing without validation!
...
✖ SWA emulator stopped because API server exited with code 1.

@cjk7989 Friday, I was able to bring my SWA up just fine locally for testing during development. Tonight, I ran everything with the exact same configuration and I get this error. Are there really no parameters I could supply to have it not reach out to a spotty third party?

Temporary solution (what I did):

1. Go to `%userprofile%\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\core\utils` (for Windows).

2. Open `user-config.js`.

3. Search for `https://json.schemastore.org/staticwebapp.config.json`.

4. Upload `staticwebapp.config.json` to blob storage (for example) or use my file: `https://stcuberdonintegration.blob.core.windows.net/assets/staticwebapp.config.json` **(Will be removed in 24H)**

5. Replace `https://json.schemastore.org/staticwebapp.config.json` with your remote path.

Thank you for solution!

I was able to patch @azure/static-web-apps-cli for my deployment pipelines to use custom url instead of https://json.schemastore.org/staticwebapp.config.json.

patches/@azure+static-web-apps-cli+1.1.6.patch

diff --git a/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js b/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
index 00861dd..0f69e81 100644
--- a/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
+++ b/node_modules/@azure/static-web-apps-cli/dist/core/utils/user-config.js
@@ -149,7 +149,7 @@ function findLineAndColumnByPosition(content, position) {
     return notFound;
 }
 async function loadSWAConfigSchema() {
-    const schemaUrl = "https://json.schemastore.org/staticwebapp.config.json";
+    const schemaUrl = process.env.STATICWEBAPP_CONFIG_SCHEMA_JSON_URL || "https://json.schemastore.org/staticwebapp.config.json";
     try {
         const res = await (0, node_fetch_1.default)(schemaUrl, { timeout: 10 * 1000 });
         if (res.status === 200) {

package.json

{
  "scripts": {
    "postinstall": "patch-package"
  },
  "dependencies": {
    "@azure/static-web-apps-cli": "1.1.6",
    "patch-package": "^8.0.0",
    "postinstall-postinstall": "^2.1.0"
  }
}

.env

STATICWEBAPP_CONFIG_SCHEMA_JSON_URL=https://example.com/staticwebapp.config.schema.json

The current error is still “Continuing without validation”. That will confuse users since it’s aborting execution.

The issue is not fixed, Static Web Apps CLI is still unstable. It’s only a matter of time before problem recurs (e.g. because of outage on schemastore)

Deployment should at least not silently destroy routes, otherwise Static Web Apps can’t be production-ready (as now). @cjk7989 can you please escalate this issue?

…

For SWA deployment in a Azure DevOps CI/CD pipeline, the recommended way is to use the “AzureStaticWebApp” task (learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/azure-static-web-app-v0?view=azure-pipelines). The CLI is mainly for local development not for production deployments. The same action exists for Github, Gitlab and Bitbucket and as container for other deployment systems.

Requiring the use of actions/tasks for deploying static assets to a web server is not a good enough solution. That’s unrelated to the problem with the CLI but then so is recommending alternatives that “don’t use it” (PS, looked at the container image manifest, it does indeed use the same tooling and scripting that the CLI uses).

Just to clarify some things in case anyone stumbles upon this issue. Neither the container image nor the GitHub/GitLab/etc. task has any dependency on the CLI and this issue is a pure CLI issue (fixed in 1.1.7). The only part of the CLI that uses the same tools as the container image is the deploy command, which still works without any problems as the validation in the deployment tooling has no dependency on the external schema and has it’s own schema validation written in C#. Currently the CLI lacks support for some parameters and variables for deployment, which is why the container image and the task are the recommended options. As the container image is available in the public MS registry, there is no requirement to use actions/tasks for deployment and like with many other projects, the container image can just be used locally if no CI system is available. I totally support improving the CLI deploy command to a level where it has the same deployment capabilities as the image/task, because not everyone has the same knowledge of containers and it would thereby reduce friction.

If you want to dive deeper or get a better understanding for the SWA-Client executable feel free to follow up offline @nathanblair.

@PothieuG I don’t think the npm package has been published yet: https://www.npmjs.com/package/@azure/static-web-apps-cli?activeTab=versions.

I imagine it’ll get published later once @cjk7989 see’s that it’s been tested by some individuals here, see the request here. I’m also guessing there are timezone limitations too

Better yet, don’t perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn’t be any hard-coded dependency on a remote server being available.

I wouldn’t use the CLI for production deployments anyway, it’s mainly made for local development and validation. You should use the GitHub action directly, as the CLI deploy command is missing a lot of configuration features for deployment like customizing data-api path’s etc. and the GitHub action doesn’t rely on the CLI.

You could even directly use the deployment container image or the StaticSitesClient directly for deployment (probably unsupported), to not be dependent on the CLI for production.

Besides that, I 100% agree that there should never be a dependency on a remote server for any local development tooling.

All of the other options rely on this under the hood. So doing anything that doesn’t rely on this isn’t an option. The real tool, the StaticClientSites binary, is kept closed source. Otherwise I’d just modify and build that directly myself and use it. This CLI tool and any other cli tool that publishes to Azure Static Sites use that closed-source binary because it’s the only way to get resources to Azure Static Sites.

That is not correct @nathanblair, the GitHub action doesn’t rely on the CLI at all, which is why that is the preferred way for production deployments. The GitHub action is just a wrapper around the SWA container (mcr.microsoft.com/appsvc/staticappsclient:stable) and you can currently use the SWA container as well as the GitHub action without problems.

There is no production tooling around SWA relying on the CLI, as the SWA CLI is mainly for local development.

Not everyone has ability to use the GitHub Action for their deployment and should not be required to do so. Again, the underlying tool should be open sourced to begin with

I hope that we can settle on the fact that “local development” does not require fetching anything from the internet. 😃

One other interesting observation that I would like to point out: I didn’t know that there is a validation until I went offline. I am not clear on why this is required and can this be optional? (activated using --strict or --validate arg)

In any case making start command not rely on the internet - that is my main request.

Thank you!

Better yet, don’t perform any validation at all at deploy time. If the schema is messed up in the config file at the time of deployment that is a fault of something that should have been fixed and adjusted at build time. And even then, there shouldn’t be any hard-coded dependency on a remote server being available.

I wouldn’t use the CLI for production deployments anyway, it’s mainly made for local development and validation. You should use the GitHub action directly, as the CLI deploy command is missing a lot of configuration features for deployment like customizing data-api path’s etc. and the GitHub action doesn’t rely on the CLI.

You could even directly use the deployment container image or the StaticSitesClient directly for deployment (probably unsupported), to not be dependent on the CLI for production.

Besides that, I 100% agree that there should never be a dependency on a remote server for any local development tooling.

All of the other options rely on this under the hood. So doing anything that doesn’t rely on this isn’t an option. The real tool, the StaticClientSites binary, is kept closed source. Otherwise I’d just modify and build that directly myself and use it. This CLI tool and any other cli tool that publishes to Azure Static Sites use that closed-source binary because it’s the only way to get resources to Azure Static Sites.

@softgandhi

I think the following measures are necessary. Add processing that allows individuals to specify Schema for development by dividing the URL that distributes Schema into multiple parts or as an option. Please have an image like the following.

swa start --schema "https://[alterbaseurl]/staticwebapp.config.json"

While I acknowledge that this issue arises due to current circumstances, it undermines the essence of validation. Allowing users to easily upload their own flawed schemas poses a risk, particularly if they become outdated and desynchronized with the latest schema over time. If validation doesn’t happen against latest schema, this could subsequently lead to additional complications in production environments.

Yes, I do not intend to use this in a production environment, but rather to use it for development to temporarily deal with issues that are currently occurring.

I think the following measures are necessary. Add processing that allows individuals to specify Schema for development by dividing the URL that distributes Schema into multiple parts or as an option.

Please have an image like the following.

swa start --schema "https://[alterbaseurl]/staticwebapp.config.json"

A quick way to use the CLI until this is resolved is to remove the “true” parameter to the logger.error method, as this causes the script to exit:

static-web-apps-cli/src/core/utils/user-config.ts

This: logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`); instead of this: logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`, true);

Credit to @cristianbretti

I disabled validation until this gets resolved:

    /*
    const schema = await loadSWAConfigSchema();
    if (!schema) {
        logger_1.logger.error(`Failed to load staticwebapp.config.json schema. Continuing without validation!`, true);
        return null;
    }
    logger_1.logger.silly(`Compiling schema...`);
    const validate = ajv4.compile(schema);
    */
    const validate = () => true;

Having a way of doing local validation is not the solution. We would still see default pipelines to fail each time someone decides to attack schemas tore.org

I think validation shloud be non-fatal at build time, it will be redone by swa api during publish. An optional parameter to force fatal errors on validation would be nice to have for some scenarios.

Yes and no… someone threw more hardware on the problem so it works for now but the problem persists. One still depends on the availability of https://www.schemastore.org/. Not quite what i would call “fixed” 😃

Temporary solution (what I did):

1. Go to %userprofile%\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\core\utils (for Windows).
2. Open user-config.js.
3. Search for https://json.schemastore.org/staticwebapp.config.json.
4. Upload staticwebapp.config.json to blob storage (for example) or use my file: https://stcuberdonintegration.blob.core.windows.net/assets/staticwebapp.config.json (Will be removed in 24H)
5. Replace https://json.schemastore.org/staticwebapp.config.json with your remote path.

Confirm this fix by @aresofficial for the issue I observed…

I’m also seeing this warning, but routes are loading okay. I am using a customised config file swa-cli-config.json

My redirect from /login causes an error and the swa auth emulator does not seem to be protecting/allowing routes correctly. Trying to determine if related to above issue or not…