Some highlights:
- Split `createNewProject.test.ts` into separate files
- Got rid of about 100 lines of "duplicate" code in `initProjectForVSCode.test.ts`
- More precise testing of `settings.json`
* Add tests for deploying CSharp and JavaScript projects
* Modify the code according to FTE's comments
* Solve the file conflict in the package.json
* Modify the code according to FTE's comments
* Modify file configuration information in package.json
* Modify the code according to FTE's comments
* Modify the code according to FTE's comments
* Modify the code according to FTE's comments
* Adjust the code format
* Update the path to match docker repo
* Update code according to the comments
* Update code according to the comments
* Update code according to the comments
* Update code according to the comments
1. Actually verify the settings passed in
1. Don't use "vscode.command.executeCommand" becuase that swallows exceptions
1. Validate that there is a test for every "Verified" template
Also split the current "Template Count" test into multiple tests. Previously the test only reported the first failure - now I can see individual failures per language/runtime/source.
As opposed to overwriting the "tasks.json" and "launch.json" files if they already exist, we will just add our config to those files. I think this is especially necessary when users have their Functions project in a sub directory because that means they could have debug configs for other projects in other sub directories.
With this project, users can debug and deploy. Biggest piece missing is creating a trigger - ultimately we'll have to wait for https://github.com/Azure/azure-functions-templates/issues/627. Because of that, I'm not showing "F#" in the prompt to create a project. User has to set "azureFunctions.projectLanguage" in user settings to "F#" _before_ creating a project to access this feature.
I found that project tests were spotty in their coverage and decided to clean up/consolidate. Now, `createNewProject.test.ts` and `initProjectForVSCode.test.ts` share a lot more logic/validation. This makes sense because ideally users end up with the same project no matter if they create it from our extension or if they create it outside of VS Code.
Also just includes more validation like checking "preDeployTask"/"deploySubpath" and more expected paths.
- Also update backup templates
- Also also fix tests
- One error that happens on nightly tests on mac
- One error that intermittently happens on windows
Ever since a few weeks ago (probably since webpack commit), tests are not running on mac (locally or in Azure Dev Ops). I couldn't figure out a root cause fix, but copying the file to this repo works for now.
I ran into two bugs while testing the release candidate:
1. The tasks.json we generate is meant to work if someone pushes their project to GitHub and clones it on a different OS. That wasn't the case for our "pipInstall" task because it always used the path separator from the _original_ OS
1. Windows users with their terminal set to bash would fail to debug
In order to fix, I ended up doing quite a bit of refactoring of venvUtils and added several tests to cover all the weird edge cases. Here's the list of terminals: https://code.visualstudio.com/docs/editor/integrated-terminal#_configuration
I also removed the logic to install "pylint" by default. It's just another command that could fail and it slows down project creation. We originally did it because the Python extension was super annoying and prompted you to install pylint every time, but now they at least have a "Don't show again" button. Fixes#814
Unit tests have been really flakey lately, especially on windows, and I don't know why. This PR does a few things to mitigate that:
1. Increase the timeout to 20 seconds for everything
1. Clean up the root test folder at the end instead of cleaning intermediary folders along the way
I was having problems with tests when I tried to run them against Insiders for this PR: https://github.com/Microsoft/vscode-azurefunctions/pull/936 These are just a few quality of life improvements that came out of that.
1. Use `mocha-multi-reporters` like stephen's done in other repos
1. Set `ext.ui` immediately. In some cases this will report "Unexpected call to showWarningMessage..." instead of a timeout
1. Added `runWithSetting` so that I had more control on when settings are used in tests. For example, if the `dispose` method of `FunctionTesterBase` failed at `fse.remove` these weren't getting set back
Nightly tests are failing with this error:
> Error: Did not find quick pick item matching '$(plus) Create new storage account'. Placeholder: 'Select a runtime for your new app.'
We now prompt for runtime if they don't have the project language set, which broke the test. I think it's more common to have the language set, so I went with that scenario to fix.
So I realized that the C# tests weren't actually running tests based on the different template sources since they overwrite the nuget package in the same location. The key fix was to change the location from:
```
path.join('resources', 'dotnetTemplates')
```
to
```
path.join('resources', 'dotnetTemplates', ext.templateSource || '')
```
The rest of the changes are based on that and a little bit of refactor. There should be no functional changes.
1. Update typescript version
1. Update tslint version
1. One of my favorite new rules is "no-implicit-dependencies" which makes sure you have a dependency listed in "package.json" if you're using it. A month-ish ago we had a problem where the storage package was listed as a devDependency instead of a dependency and this rule would've prevented that
1. Update to next alpha
1. Clean up tasks.json/launch.json
1. Set 'DEBUGTELEMETRY' on launch since gdpr is updated daily now
Includes the following:
1. Fix template tests so that we guarantee it's testing against cli feed _and_ backup templates (current code was just testing against cli feed twice)
1. Remove a little bit of duplicate code in suiteSetup
1. Turn off telemetry for tests
1. Allow running a subset of tests with MOCHA_grep (super excited about this one - thanks Stephen)
Create and locally debug Python functions projects. Option to create is still hidden as Python is still in preview and we are working on the deployment scenario.
In order to debug, `python -m pip install --pre ptvsd` must be run within the project's virtual environment. There is also a dependency on the experimental Python Extension, but they should release on Tuesday, 9/5/2018.
Since we now have more templates available, I tried to make this list match the verified templates for JavaScript. v2 is exactly the same for both (just 4 templates). JavaScript has 8 for v1 while C# only has 7 (it's missing the ManualTrigger for some reason).
I also moved the warning to after all of the function-creation stuff. That ways its less in-your-face. Plus creating a storage account can take a while and we don't want to stop the user from creating a function during that time
I honestly don't think users will change their runtime/language very often - this is much more about the visibility of the settings. Previously user's didn't know the settings even existed and didn't know what it was set to. That's why I wanted to make sure these never show up at the top as "(recently used)".
The other big difference is that JavaScript projects will now default the runtime to the user's locally installed runtime (if we can detect the version). The positive: Users will have more consistent behavior between their local/remote function apps. The negative: "beta" users will see many fewer templates since "beta" doesn't have as many as "~1"
This fully moves over to the shared UserInput. A few highlights:
1. My old implementation of QuickPickItems, showInputBox, and showQuickPick in this repo had actually diverged from the vscode implementation. I regret doing that now and a lot of this is just moving back to the vscode patterns
1. Remove a custom implementation of displaying subscriptions and switch over to showNodePicker
1. Make the 'showWorkspaceFolder' more similar to app service extension (where it displays path.basename as the label and the full path as the description)
This lets us use `callWithTelemetryAndErrorHandling` for validating projects. I also added the validateProjects command to run with the onDidChangeWorkspaceFolders event
On extension activation, we will check for unitialized functions projects based on the following criteria:
1. host.json and local.settings.json exist
1. projectLanguage and projectRuntime are not set
We will then initialize the project in the following manner:
1. If we can _uniquely_ detect the language - use that. If we can't, prompt the user for the langauge
1. If we can detect the installed runtime - use that. Otherwise, prompt the user for the runtime
1. Remove '.vscode' from the gitignore if applicable
NOTE: I also added a command so that user's can call this from the command palette if they so desire
This is better in a few ways:
1. It eliminates the need for the settings to always be in the same order
1. It allows us to add optional parameters in the future in a backwards compatible format
For the 64 bit warning, it now opens the link directly with a 'See more info' instead of having to copy the link. There's also a 'Don't warn again' option
Our project settings were being completely ignored in multi-root workspaces. Here's what I did to fix that:
1. Declare our project-based settings as 'resource' scope (If you use the default scope of 'window', then settings only apply at the user/workspace level - not the workspaceFolder level)
1. Pass the projectPath in when getting settings so that the specific folder takes precedent
1. Modify the workspace folder picker so that it dynamically gets the subpath for each folder
1. Fix 'update' for mutli-root settings: If you don't pass the ConfiguratonTarget, it uses the appropriate scope from the configuration (Workspace vs WorkspaceFolder)
1. Allow windows users to install either the .NET Core _or_ .NET Framework templates
1. Provide commands to install/uninstall the templates
1. Limit function templates to just the main 4
1. Detect if the project created was .NET Core or .NET Framework and set runtime accordingly
This supports project/function creation and local debugging. It does not include deploy logic.
A brief summary:
1. We default C# projects to beta runtime and class library (instead of C# script)
1. We use dotnet templates for project/function creation. We will automatically install the templates for the user if they are not on their machine (I don't prompt at all - let me know if you think we should prompt).
1. We use the parameter information from the functions portal (Aka C# Script templates) since it's easier to parse than the dotnet cli and it gives us more information (like validation). This requires us to assume that parameters for C# Scripts are the same as the parameters for the C# Class libraries. Since that might not always be the case, I mitigated this with unit tests and hard-coding the version of the dotnet templates.
1. Unlike JavaScript debugging, we have to attach to a specific process instead of attaching with a port. I implemented a 'pickProcess' command to search for the functions host process.
1. This only works on Windows. There's a few issues on a Mac I still need to iron out.
Turns out we want to add support for class libraries (.cs), but this code added support for C# script files (.csx). I want to leave this code in the git history in case we add support for .csx _in addition_ to .cs
* Add CSharp to the list of options when creating a new project
* Add setting for projectLanguage
* The user has many options for language, but only C#/Java/JavaScript can be debugged in VS Code today. The rest only support create & deploy
* If it's not set (for example in old projects before this release), the user will be prompted one time and their workspace setting will be updated
* Add setting for projectRuntime
* We want to use ~1 for JavaScript and beta as the default for Java/C#
Eric Jizba
v-wuzhai
Nathan
Francisco Gamino
Tyler James Leonhardt
Hanxiao Liu
Stephen Weatherford