spfx project upgrade resulting in SyntaxError: Unexpected token _ in JSON at position 1078

[tcattermole]

Hi

I've been going around and around in circles trying to generate project upgrade instructions for an SPFx 1.10.0 project that I wish to upgrade. I have cli-microsoft365 installed just fine but running spfx project upgrade (with or without providing options) is consistently returning the following error.

m365 spfx project upgrade --toVersion 1.12.1 --output md > "spfxupgrade.md" --verbose --debug
Executing command spfx project upgrade with options {"options":{"toVersion":"1.12.1","output":"md","verbose":true,"debug":true}}
Collecting project...
Error: SyntaxError: Unexpected token _ in JSON at position 1078

I've tried different upgrade targets to no avail. I feel like I could resolve this issue if the error provided were more precise ... unexpected token in WHAT json in particular? Has anyone else come across something similar or have any suggestions?

Thanks,
Terry

[milanholemans]

Hi @tcattermole

Sorry to hear that you are struggling to use spfx project upgrade. I agree that the error message is not very clear indeed. We should have a look if we can improve this.
To help you out a bit, please check the following files for an invalid _ character (maybe use an online JSON validator tool).

• package.json
• .yo-rc.json
• tslint.json
• all JSON files in your config folder
• all JSON files in your .vscode folder

Hope this will help.

[waldekmastykarz]

To add to it, also web part manifests could be a culprit.

[tcattermole]

Thank you both so VERY much for the guidance on where to look ... it took a bunch of time but I did indeed find the offending JSON! Tucked away in the webpart manifests (in vsts folders under each webpart) were various "placeholders" for DevOps pipeline variables starting with "__". The vast majority of these were within quotes but 3 (of about 30 webparts and an app customizer) had entries not in quotes. This hasn't affected the project's compilation, which kinda surprises me, but was of course not valid JSON. So ... success. Now I have my list of steps to upgrade. A daunting task still given the size of the solution but at least I know where to start.

Again, thank you both very much.

May I ask a follow-up question? The primary reason for doing this SPFx upgrade is of course because it is overdue and good practice. The other is prompted by the upcoming retirement/deprecation of ADAL in favor of MSAL. I will be honest up-front and state that authentication is not my strongest point. Looking under the hood of the AADHttpClient (which we use) in our current 1.10.0 project I see references to it using ADAL but a future upgrade to MSAL. Is this something implemented in the sp-http package required by 1.12.1? Or am I misunderstanding the nature of this migration from ADAL to MSAL (at least insofar as it affects SPFx solutions in SPO) and is it something handled in the "plumbing" by SPO and so entirely independent of the SPFx version used? Apologies for the tangent!

Terry

[waldekmastykarz]

Your follow up question would be better suited for https://github.com/SharePoint/sp-dev-docs/issues/new?assignees=&labels=Needs:+Triage&template=question.yml where you can get authoritative answer from SharePoint engineers.

[tcattermole]

Thank you. Will do! Thanks again for the help.

[waldekmastykarz]

Yeah, that's useless indeed. Sorry @tcattermole, and we should definitely do better. Is there a chance for you to share the SPFx project with us so that we can find out what's wrong and see if we can fix the issue? Once again, sorry for the trouble and we appreciate you reporting the issue.