Provide IDE-like experience for viewing/editing Node.js functions in the portal

[kichinsky]

Updated AF tools allow to create TypeScript-template for Azure Functions in VSCode, that is great.

1. Displaying files from the /dist folder
   The structure of the project suggests that after ts-files are compiled, the output js-files are store in the /dist folder.

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es2017",
    "outDir": "dist",
    "rootDir": ".",
    "sourceMap": true,
    "strict": false
  }
}

The function.json file in the function folder also references to that dist folder. 👍
The portal in the editing interface by default opens files from the dist folder. 👍

But when I go to the "View files" tab, I can't find the source index.js file. ☹

2. Recompile ts files through the portal.
   It would be helpful to automatically compile/recompile .ts-files if I'm able to edit them through the portal. But probably, I don't want to install tsc on the app level. ☹

I know that it is not so easy to implement it without complicating other things.. But the current experience is somehow incomplete. You allow editing files, but it makes no sense, as they are not compiled.

3. I understand that it is up to the developer to figure out such things, but the node-version that is used in AF at least supports ES2018, and the default target version for TS in the template is ES2016. It seems like a common default across the industry, but it would be helpful to expose somehow to developers, that they can level up target version up to ES2018 (e.g., in docs or in comments in the template).

[pragnagopa]

@mhoeger - Please take a look.

[mhoeger]

@kichinsky - thanks for taking a look and for the feedback!! How did you deploy to get to this state? The flow we want developers to follow is to develop and test functions locally and then publish (by default, it publishes as "read-only"). For further changes, the expectation was to make them locally and then publish. Could you tell us how you got to using the TypeScript template but not publishing as read-only (using run-from-package)?

[kichinsky]

@mhoeger I'm using ADO Pipelines to deploy from the typescript source code (I had to add compiler step on build to make it pass through). You are right, by default as soon as I configure CI/CD it is readonly, but...

1. When I attemp to explore the files by default the portal opens the index.js file, but it is not available in the list of files:
   

So it is not about editing, just looking through the code.

2. I can turn off the read-only mode, and I can still edit files through the App Service Editor. Meanwhile it is against CI/CD practices, it still makes sence for experiments and live tunning/debugging. So in such a case I would prefer to edit TS-files, but I have to compile them then.

[mhoeger]

@kichalla - I still struggle with this scenario because our local debug/tuning is going to run the same code paths as production. I definitely understand the convenience of being able to adjust deployed code, but we've seen a lot of mistakes in the past from being able to directly alter production code and we're trying to move away from this dangerous game.

We'll keep this under consideration, but it's hard to justify putting in a good chunk of dev hours to simplify a scenario we want to discourage. Would making remote debugging easier meet your needs? That's something we are more inclined to invest in across languages / across scenarios.

[kichinsky]

@mhoeger I think it is more complicated meanwhile the ultimate goal is still to simplify and streamline developer experience.

The way how I hear what you say is that there some dangereous practices (e.g., editing on deployment) and we are trying to get rid of them (by pushing towards local testing and strong CI/CD pipeline). But having front-end background I feel that there is a mismatch in that approach. And it lays in a different place.

1. There are use cases when I just wanna get something live in the cloud quickly. For context - it is usually on the prototyping stage, when I don't really care about production constrains, etc. My only goal is to get it work. Then for me, it is easier to setup continuous deployment with something like ADO Pipelines than manually trigger uploading from VS Code. But... executing ADO Pipeline for each update takes time. So now, when I just need to fix one line of code and see, if it works, it is much faster to do it through the portal, check whether it works and update than in the source code, redeploy, etc. My motivation is to do what is faster, not what is more secure.

2. Than if I have a front-end background, than it is in my DNA to trust real execution vs. local testing. It is my habbit to alter code through debugging tools built-in to the browser, to edit almost live-code and see changes. Just one small example: if I didn't install locally dotnet, I can't install CosmosDB extensions, then I can't test it locally, etc -- but if I add binding through the portal it happens automatically. So my trust is already broken with local testing/running. Now the question is how I can continue doing it my way without sacrificing security, stability, etc. I don't say that it should be all live in cloud (meanwhile I can image a prototyping-staging without constrains). I just say that we should take into account the developer nature instead of trying to alter it just because we think that our way is the right one. The question N1 is how to increase the trust in local testing, and the question N2 is how to allow that live-editing that is natural for most of front-end (web-) developers?

[vamsi981]

@kichinsky any Luck on the CI/CD with the Typescript, we are also facing the same issue directly we can't able to push typescript based functions :(

[kichinsky]

@vamsi981 My current setup to deploy Azure Functions (AF) on TypeScript through Azure DevOps (ADO) is the following:

1. In AF portal -- setup the source code and CI/CD to use ADO. It will generate some standard pipelines for build and deploy.
2. For the source code - ensure you have the extensions.csproj file (run func extensions install) in your folder. It will capture the dependencies from your integration points. You need to install the Azure Functions Core Tools before running the func command.
3. In the ADO in your build pipeline:

• Add Compile TypeScript step (there is an extension in the marketplace, that you can easily search from the interface). Ensure you configured the path to the source folder or your tsconfig.json.
• Add a new Bash step with two commands:

dotnet restore extensions.csproj
dotnet build extensions.csproj --output ./bin/

Configure the working directory for this step as well.

[ejizba]

We are aware of the issues for in-portal editing of TypeScript functions and there will be even more issues for both JS and TS once we implement #480 (because the new programming model will require a certain amount of app-level code, not just one js/ts file per function).

I'm skeptical we will fix these with the existing in-portal editing, but there's talk of doing a prototype with GitHub Codespaces to replace in-portal editing. If that works happens, it would not be for a while and also would not be specific to Node.js - so I'll put this in the tracking milestone for now