Question 171501 in Azure Question posted in
The official documentation to get you started can be found here.

Why is Azure web app service giving a “SyntaxError: Unexpected token” after updating VS Code?

UPDATE 5/18/23 – I updated this in Azure application setting from 6.9.1 to 18 (node version I’m using) and now I can deploy successfully again.

WEBSITE_NODE_DEFAULT_VERSION

PROBLEM

I’m not sure why my deployment is failing. I had this issue before in VS Code 1.65 to 1.66 and had to stay on 1.65. There was a VS Code update to 1.78.2 from whatever the previous version I was on.

I tried downgrading to the March 2023 version of VS Code and retried deployment, but still had the same failure. (FYI – still had version 1.78.2 open and running as I tried to perform a deploy using the March version) so don’t know if that makes a difference?

Here is what I see in the output. I’m not sure what this means? How can I debug this? I have application logging turned on in Azure, but don’t see anything in the log stream when I try to deploy. I also opened Kudu (*.scm.azurewebsites.net) and looked through the files but didn’t see anything useful. Maybe I’m not familiar enough with Kudu to understand how to use it to debug a failed deployment.

    6:42:56 PM yoga-dev-1: Starting deployment...
    6:42:59 PM yoga-dev-1: Creating zip package...
    6:43:10 PM yoga-dev-1: Zip package size: 29 MB
    6:43:10 PM yoga-dev-1: Fetching changes.
    6:43:11 PM yoga-dev-1: Cleaning up temp folders from previous zip deployments and extracting pushed zip file C:localTempzipdeployqkztvba1.zip (27.71 MB) to C:localTempzipdeployextracted
    6:43:17 PM yoga-dev-1: Updating submodules.
    6:43:17 PM yoga-dev-1: Preparing deployment for commit id '7e83110e5b'.
    6:43:17 PM yoga-dev-1: Generating deployment script.
    6:43:17 PM yoga-dev-1: Using the following command to generate deployment script: 'azure site deploymentscript -y --no-dot-deployment -r "C:localTempzipdeployextracted" -o "C:homesitedeploymentstools" --basic --sitePath "C:localTempzipdeployextracted"'.
    6:43:18 PM yoga-dev-1: C:PROGRA~2SITEEX~1NODEAP~1296456~1.8
    6:43:18 PM yoga-dev-1: odejsbuildsrcLoader.js:153
    6:43:18 PM yoga-dev-1:                 ...StatusLogger.DEFAULT_STATUS,
    6:43:18 PM yoga-dev-1:                 ^^^
    6:43:18 PM yoga-dev-1: SyntaxError: Unexpected token ...
    6:43:18 PM yoga-dev-1:     at createScript (vm.js:56:10)
    6:43:18 PM yoga-dev-1:     at Object.runInThisContext (vm.js:97:10)
    6:43:18 PM yoga-dev-1:     at Module._compile (module.js:542:28)
    6:43:18 PM yoga-dev-1:     at Object.Module._extensions..js (module.js:579:10)
    6:43:18 PM yoga-dev-1:     at Module.load (module.js:487:32)
    6:43:18 PM yoga-dev-1:     at tryModuleLoad (module.js:446:12)
    6:43:18 PM yoga-dev-1:     at Function.Module._load (module.js:438:3)
    6:43:18 PM yoga-dev-1:     at Module.require (module.js:497:17)
    6:43:18 PM yoga-dev-1:     at module.js:669:12
    6:43:18 PM yoga-dev-1:     at Array.forEach (native)
    6:43:18 PM yoga-dev-1: C:PROGRA~2SITEEX~1NODEAP~1296456~1.8
    6:43:18 PM yoga-dev-1: odejsbuildsrcLoader.js:153r
    6:43:18 PM yoga-dev-1:                 ...StatusLogger.DEFAULT_STATUS,r
    6:43:18 PM yoga-dev-1:                 ^^^r
    6:43:18 PM yoga-dev-1: r
    6:43:18 PM yoga-dev-1: SyntaxError: Unexpected token ...r
    6:43:18 PM yoga-dev-1:     at createScript (vm.js:56:10)r
    6:43:18 PM yoga-dev-1:     at Object.runInThisContext (vm.js:97:10)r
    6:43:18 PM yoga-dev-1:     at Module._compile (module.js:542:28)r
    6:43:18 PM yoga-dev-1:     at Object.Module._extensions..js (module.js:579:10)r
    6:43:18 PM yoga-dev-1:     at Module.load (module.js:487:32)r
    6:43:18 PM yoga-dev-1:     at tryModuleLoad (module.js:446:12)r
    6:43:18 PM yoga-dev-1:     at Function.Module._load (module.js:438:3)r
    6:43:18 PM yoga-dev-1:     at Module.require (module.js:497:17)r
    6:43:18 PM yoga-dev-1:     at module.js:669:12r
    6:43:18 PM yoga-dev-1:     at Array.forEach (native)r
    6:43:18 PM yoga-dev-1: C:Program Files (x86)SiteExtensionsKudu100.50331.6204binScriptsstarter.cmd "C:Program Files (x86)SiteExtensionsKudu100.50331.6204bin
    6:43:18 PM yogabandy-dev-1: ode_modules.binkuduscript.cmd" -y --no-dot-deployment -r "C:localTempzipdeployextracted" -o "C:homesitedeploymentstools" --basic --sitePath "C:localTempzipdeployextracted"
    6:43:19 PM yoga-dev-1: Deployment Failed.
    6:43:29 PM yoga-dev-1: Deployment failed.

UPDATE – Looking at my notes, on April 8, 2022 I had an issue with VS Code 1.66.1 where I was experiencing the same issue with failures in my web app deployment. So I downgraded to VS Code 1.65.2 and it worked again.

QUESTION – Is there something I can look into to see if there is some compatibility issue between VS Code, Azure and the web app I’m deploying? I checked the web app service and it’s using .Net 6 as is my application. I rebooted my Mac, restarted VS Code. Not sure what else I can do to see if resetting something might help!

Tags:

2

Answers


  1. 0

    There’s an issue with the Node.js Loader module, implying that there is an incompatibility or configuration issue with the version of Node.js being used.

    Check the node.js version with node --version command and configure your environment as detailed in the below doc.

    1. Configure the environment,
    2. Update it to Node.js version 18.x, Azure functions core tools 4.x & Function Runtime Version: 4.17.x,
    3. Check Visual Studio Code latest releases and upgrade it.

    In my local environment there is a node.js v16.17.0 installed already. Once I created the .js function in Azure functions locally, I ran the function, it shows a warn as below. With that, I also received the same error as you.

    enter image description here

    Then, I updated it to v18.0 and it started working as expected.

    Note: Before upgrading to any latest versions/releases, make sure that you are uninstalling the previous ones and install the specific release version.

    Install Node.js v18.12.0

    After the above changes, I ran the sample trigger function with a Hello world message and was able to trigger it.

    enter image description here

    enter image description here

    Deployed successfully after updating with the compatible versions:

    enter image description here

    You can also check the function runtime settings FUNCTION_WORKER_RUNTIME, FUNCTIONS_ENTENSION_VERSION and others in the application settings are set properly with the desired version values.

    enter image description here

    Note: Check that the version of the locally created function runtime and the version of the deployed function runtime in Portal are the same and do not conflict.

    Once it is deployed into function app, you can view the logs from log stream in the monitoring section as shown.

    enter image description here

    Or else,

    You can follow the below URL by replacing it with your function App name to retrieve all the logs.

    Log stream: https://newaps.scm.azurewebsites.net/api/logstream

    enter image description here

    Refer for Azure Functions runtime Versions compatibility.

    Login or Signup to reply.
  2. 0

    As I commented, the version of Node.js used by Azure during the deployment process may be different from the one you are using locally.

    Azure uses the version specified in the WEBSITE_NODE_DEFAULT_VERSION app setting, the node property in the engines section of the package.json file, or a default version if neither of these are provided.

    • Make sure that a version of Node.js that supports the spread operator (5.12.0 or later) is being used during deployment.
    • Set the WEBSITE_NODE_DEFAULT_VERSION app setting in the Azure portal or specify the node version in the engines section of your package.json file.

    The OP confirms:

    I updated WEBSITE_NODE_DEFAULT_VERSION in Azure application setting from 6.9.1 to 18 (node version I’m using), and now I can deploy successfully again.

    The engines field in package.json is not mandatory, and if it’s not present, Azure will use the version specified in the WEBSITE_NODE_DEFAULT_VERSION app setting.
    However, specifying the Node.js version in package.json can be useful to ensure that your application is always run with a compatible version of Node.js, regardless of the environment it’s deployed in.

    The engines field in package.json specifies the version of Node.js that your project is compatible with. It is usually found at the root level of the package.json file.
    If it’s not present, you can add it manually.

    That would be something like:

    {
  "name": "your-app",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo "Error: no test specified" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "engines": {
    "node": "16.x"
  }
}

    In this example, the engines field specifies that the project should be run with Node.js version 16.x. You can replace "16.x" with the version of Node.js that you are using.

    The "*" value in your package-lock.json file means that your application should work with any version of Node.js. The package-lock.json file is generated automatically and should not be edited manually. Instead, any changes to the Node.js version should be made in the package.json file, and the package-lock.json file will be updated automatically the next time you run npm install.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search