Merge pull request #799 from nagilson/nagilson-axios

Migrate to Axios to fix caching bugs & Reduce development burden + Other QOL Fixes

Author: nagilson

CODE_OWNERS.txt

@@ -1,15 +1,4 @@
-The following is a list of owners for different areas of the VSCode .NET Core extension code. 
-Each of the owners is responsible for ensuring that changes in their areas 
-are reviewed, either by themselves or by someone they designate, in 
-addition to being the final word for the architecture and content of an area.
+# CODEOWNERS file per https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
 
-List sorted by last name and the fields are Name (N), GitHub user account (G), 
-Description (D).
-
-Note: If you don't find the area in the below list, or you have a general 
-question, send a message to Sarah Oslund (@sfoslund) or Marc Paine (@marcpopMSFT). 
-They can ensure that the question gets forwarded to theright person or answer it themselves.  
-
-N: Sarah Oslund
-G: sfoslund
-D: Everything
+# Default owners
+* @dotnet/dotnet-cli

Documentation/contributing-workflow.md

@@ -21,7 +21,14 @@ We use and recommend the following workflow:
 4. Make and commit your changes.
     - Please follow our [Commit Messages](contributing.md#commit-messages) guidance.
 5. Add new tests corresponding to your change, if applicable.
-If you are having difficulty debugging changes, note that you can add breakpoints into the tests for the library, runtime, or SDK by opening their corresponding workspace folder and launching the debug tab for their tests in VS Code. If you want to breakpoint the code, you'll need to breakpoint the test in typescript, but then every reload add breakpoints to the JS code generated from the typescript code if you want to debug code outside of the tests thesmelves that the tests run.
+
+If you are having difficulty debugging changes to the library, you may want to incorporate the logging messages into your test session. To do so, set the debugOn flag to true [Here](../vscode-dotnet-runtime-library/src/Utils/Debugging.ts).
+Note that the runtime and sdk extensions can be tested (with breakpoints as well, through the .js files) using their corresponding workspace and launch profiles by opening their root folders in vscode.
+For the library, those tests are reachable by going through the runtime extension workspace and adding the runtime-library folder to the workspace. But logging may be a better approach to debug this code.
+
+
+If you are having difficulty debugging all other changes, note that you can add breakpoints into the tests for the library, runtime, or SDK by opening their corresponding workspace folder and launching the debug tab for their tests in VS Code. If you want to breakpoint the code, you'll need to breakpoint the test in typescript, but then every reload add breakpoints to the JS code generated from the typescript code if you want to debug code outside of the tests thesmelves that the tests run.
+
 6. Build the repository with your changes.
     - Make sure that the builds are clean.
     - Make sure that the tests are all passing, including your new tests.

azure-pipelines.yml

@@ -41,7 +41,7 @@ stages:
     steps:
     - task: NodeTool@0
       inputs:
-        versionSpec: '15.x'
+        versionSpec: '16.10.0'
       displayName: 'Install Node.js'
     - script: build.cmd
       displayName: Build Windows
@@ -75,7 +75,7 @@ stages:
     steps:
     - task: NodeTool@0
       inputs:
-        versionSpec: '15.x'
+        versionSpec: '16.10.0'
       displayName: 'Install Node.js'
     - bash: |
         npm install --cache /temp/empty-cache
@@ -98,11 +98,11 @@ stages:
         scriptSource: 'filePath'
         scriptPath: 'dependency-verifier.py'
         arguments: '$(System.PullRequest.TargetBranch)'
-        failOnStderr: true  
+        failOnStderr: true
   ##### Package and Publish #####
   - job: Package
     displayName: 'Package and Publish'
-    dependsOn: 
+    dependsOn:
     - Build
     - TSLint
     condition: succeeded()
@@ -119,7 +119,7 @@ stages:
     steps:
     - task: NodeTool@0
       inputs:
-        versionSpec: '15.x'
+        versionSpec: '16.10.0'
       displayName: 'Install Node.js'
     - bash: |
         if ([ $(is-sdk-release) = 'True' ] && [ $(package-name) = 'vscode-dotnet-sdk' ]) || ([ $(is-runtime-release) = 'True' ] && [ $(package-name) = 'vscode-dotnet-runtime' ]); then

dependency-verifier.py

@@ -77,7 +77,7 @@ def NpmChangesMirrorYarnChanges(changedFiles, packageLockPath, targetBranch):
     else:
         outOfDateYarnLocks.append(yarnLockPath)
     if(outOfDateYarnLocks != []):
-        sys.exit(f"The yarn.lock and package-lock appear to be out of sync with the changes made after {targetBranch}. Update by doing yarn import or yarn add dep@package-lock-version for {outOfDateYarnLocks}. For sub-dependencies, try adding just the main dependency first.")
+        sys.exit(f"The yarn.lock and package-lock appear to be out of sync with the changes made after {targetBranch}. Update by first using npm to push to the registry, doing npm install package@version. Then, do yarn add package@version for {outOfDateYarnLocks}. During the yarn add process, you may need to npm install specific dependencies that yarn will flag to allow yarn to proceed. You may consider (yarn import). Note this tool will list dependencies of packages, but you should try adding just the main package first. If you can confirm the new changes are in sync, then you may ignore this failure.")
     else:
         return 0 # OK, status here is not used
 

package-lock.json

@@ -15,5 +15,8 @@
 	},
 	"dependencies": {
 		"vsce": "2.11.0"
+	},
+	"devDependencies": {
+		"@types/source-map-support": "^0.5.6"
 	}
 }