Since I was working in Visual Studio Code, I added the function to my Azure Static Web App using the Azure Static Web Apps: Create HTTP Function... command provided by the Azure Static Web Apps extension.

The template created all the plumbing for me in the api directory of my repository, including everything that was needed for building and running the functions locally: the scripts in package.json file, as well as the tasks and launch targets for Visual Studio Code. After I also installed Azure Functions Core Tools, I could run and test the function locally before deploying it to Azure.

My code depended on some static data in a JSON file, which I imported into my source code file. While I did it using the resolveJsonModule compiler option, the Azure Function worked as expected.

But once I used the allowArbitraryExtensions compiler option instead, to allow for custom type definition for my JSON file, the Azure Function was simply gone: Any calls to it returned 404 and the APIs settings page of my Azure Static Web App didn't show any deployed functions. To make matters worse, I couldn't find any error logs anywhere: not in Azure Portal and not in GitHub Actions which I used for deployment. I couldn't even enable Application Insights in the Azure Static Web App settings, because I supposedly didn't have any functions:

Fortunately, I could reproduce the issue by trying to run the function locally. It failed to run with the following error:

Worker was unable to load entry point dist/src/functions/persons.js: Cannot find module ./persons.json

Further research revealed that the build script copied the JSON file to the output folder as long as it depended on the resolveJsonModule compiler option, but not anymore after I started relying on the allowArbitraryExtensions compiler option to use custom type definitions.

Two scripts from the generated packages.json file were relevant for my issue:

{
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w"
  }
}

The build script was used during deployment, and the watch script was used when running the function locally. Both simply invoked the TypeScript compiler to generate the JavaScript files and copy the results to the output folder. I guess, the compiler copies the JSON files which are resolved as JSON modules but no the ones which are considered having arbitrary extensions.

I wasn't really keen on introducing a bundler for the build process, so I decided to simply copy the JSON files across during the build process as suggested by Jan Asgaard in his blog post. I installed the copyfiles package:

npm install --save-dev copyfiles

And used it to copy the JSON files from the relevant script files:

{
  "scripts": {
    "build": "tsc && copyfiles \"src/**/*.json\" dist",
    "watch": "copyfiles \"src/**/*.json\" dist && tsc -w"
  }
}

In the build script, I could run it after the compiler was done, but in the watch script I had to do it before invoking the compiler because its process kept running to watch for file changes. My approach also meant that the JSON files were not going to be updated automatically in the output folder if I changed them while the the compiler file watch was active. That was good enough for me.

With this change, the function worked again after the next deploy to Azure Static Web Apps.

You can find a sample project in my GitHub repository. Individual commits follow the steps described in this post:

• a working function using resolveJsonModule,
• a broken function using allowArbitraryExtensions,
• and a working function again with the modified build and watch scripts.

The repository also includes a GitHub Actions workflow to deploy the sample site with the function to Azure Static Web Apps. Of course, you'll have to create your own Azure Static Web App in order to do that, and store the deployment token for it in the AZURE_STATIC_WEB_APPS_API_TOKEN secret in GitHub Actions.

I find it interesting that the handling of JSON files by the TypeScript compiler depends on how you import them into the source code file. In a way, that is also documented, although it might not be obvious until you are aware of that behavior:

By default, this import will raise an error to let you know that TypeScript doesn’t understand this file type and your runtime might not support importing it. But if you’ve configured your runtime or bundler to handle it, you can suppress the error with the new --allowArbitraryExtensions compiler option.

Although using a bundler would be a proper solution in such a case, I find it an overkill for my scenario. Simply copying the files to the output folder works well enough for now. I can always introduce a bundler in the future if I need to.

To make imports work with JSON data, you need to enable resolveJsonModule in your tsconfig.json file (it seems to be enabled by default when you have module compiler option set to node20 or nodenext, but it doesn't hurt to set it explicitly anyway):

{
  "resolveJsonModule": true
}

Then you can import a JSON file just like a regular TypeScript file:

import lookups from "./lookups.json";

This initializes a lookups variable with the data from the JSON file and you can use it in your code like any other variable:

for (const lookup of lookups) {
  // ...
}

And it's not even typed as any. The compiler assigns it a type which matches the file contents.

In many cases this works good enough. But it made the types too specific for my use when I was dealing with a key value dictionary:

[
  {
    "separator": ",",
    "index": 2,
    "lookups": {
      "one": "1",
      "two": "2",
      "three": "3",
      "four": "4",
      "five": "5"
    }
  },
  {
    "separator": ";",
    "index": 1,
    "lookups": {
      "1": "a",
      "2": "b",
      "3": "c",
      "4": "d",
      "5": "e"
    }
  }
]

When I tried to access the lookups dictionary field by a string key, I got a compiler error:

When I took a look at the type the compiler prepared for me, it quickly became obvious why it didn't work:

const lookup:
  | {
      separator: string;
      index: number;
      lookups: {
        one: string;
        two: string;
        three: string;
        four: string;
        five: string;
        "1"?: never;
        "2"?: never;
        "3"?: never;
        "4"?: never;
        "5"?: never;
      };
    }
  | {
      separator: string;
      index: number;
      lookups: {
        "1": string;
        "2": string;
        "3": string;
        "4": string;
        "5": string;
        one?: never;
        two?: never;
        three?: never;
        four?: never;
        five?: never;
      };
    };

The type was much too specific for my needs. I wanted the lookups field to be treated as a Record<string, string>.

Fortunately, there's a way to specify your own type definitions for data from an imported JSON file. To make it work, you need to set the allowArbitraryExtensions compiler option instead of resolveJsonModule:

{
  "allowArbitraryExtensions": true
}

Then you can create a type definition for your JSON file with the same base filename, but with a .d.json.ts extension instead of .json, i.e., for my lookups.json file I had to create a type definition file lookups.d.json.ts with the following contents:

declare const lookups: {
  separator: string;
  index: number;
  lookups: Record<string, string>;
}[];

export default lookups;

With these two changes, the compiler imported the JSON file with my types instead of its own implied ones. And with that, the compiler error for my dictionary lookup by key was resolved.

You can find a sample project in my GitHub repository. The last commit showcases the approach with the allowArbitraryExtensions compiler option and the one before that uses the resolveJsonModule compiler option.

Although resolveJsonModule works great for importing JSON files in most cases, it's good to know that there is an option to override default implied type information when you need to by using allowArbitraryExtensions. Just keep in mind that it's your responsibility to make sure that the data in the JSON file matches your type definition. Otherwise you can expect run-time errors in your application when accessing that data.

The breakpoint icons included a warning icon and when I hovered over them, the following message appeared in the tooltip:

The breakpoint will not currently be hit. No symbols have been loaded for this document.

Usually this happens when no symbol (.pdb) file is available next to the plugin assembly (.dll) file or when it's out-of-date and it doesn't match the assembly. I followed my standard procedure for resolving such an issue:

• close the application,
• rebuild the plugin project,
• copy the new assembly and symbol file to application plugin folder,
• restart the application,
• and attach the debugger to its process again.

However, breakpoints still didn't work. They worked flawlessly the previous time I worked on the plugin, and I couldn't recall making any changes to my Visual Studio setup that would cause the issue.

I checked out the version of the plugin I worked on that time and repeated the whole rebuild and redeploy process. The breakpoints worked as expected. I tried it again with the latest version and the breakpoints stopped working.

The only explanation I could think of was that between the two versions of the plugin something has changed that broke the breakpoints (at least for me). Fortunately, there weren't too many changes and I quickly noticed one that looked like a potential culprit. The following line was added to the project (.csproj) file with one of the commits:

<PathMap>$(MSBuildProjectDirectory)=/_/</PathMap>

I wasn't familiar with that MSBuild property, so I looked it up in the documentation:

Specifies how to map physical paths to source path names output by the compiler. This property is equivalent to the /pathmap switch of the compilers.

This confirmed my suspicion: the property interferes with the source file paths in the symbol files. I tried removing the offending line: after a rebuild and redeploy, breakpoints worked again.

To see how exactly the property affects the symbol files, I opened both of them in a text editor and searched for a random .cs file reference in it:

• The symbol file built without the PathMap property contained the absolute path to the source file on my disk: C:\Users\Damir\Git\PluginSln\PluginProj\SourceDir\SourceFile.cs.
• The symbol file built with the PathMap property had the absolute path to the solution directory replaced with /_/: /_/PluginProj/SourceDir/SourceFile.cs. Because of this change, the Visual Studio debugger failed to map the source files.

I'm not sure what the benefit of such PathMap setting is except if you plan to distribute the symbol files and don't want them to give away the absolute paths from the machine they were built on.

Since it's not my plugin project, I didn't want to commit my reversed change. Instead, I created a git stash with the PathMap change removed which I can apply whenever I work on the plugin and need to debug it. And I make sure not to commit the change when I contribute to the project.

The backup script relies on the Bitwarden CLI. I installed it using Chocolatey:

choco install bitwarden-cli

Unlike the original script, I wanted to run my on a schedule and non-interactively. I stored my credentials in a separate script file that's only accessible with elevated privileges as described in a previous blog post:

$env:BW_CLIENTID = "client_id"
$env:BW_CLIENTSECRET = "client_secret"
$env:BW_PASSWORD = "password"

The BW_PASSWORD environment variable contains my Bitwarden password. The values for BW_CLIENTID and BW_CLIENTSECRET can be accessed from the Security Settings page of Bitwarden web interface:

My backup script starts by invoking the script with my credentials, which stores them in the documented environment variables. I then log in using the API key and unlock the vault using the password from the specified environment variable. I store the returned session key into another environment variable:

bw login --apikey
$sessionKey = bw unlock --passwordenv BW_PASSWORD --raw
$env:BW_SESSION = $sessionKey

This is enough to make vault contents accessible through CLI commands.

I export the vault into an unencrypted JSON file since it's encrypted by restic anyway:

$backupFile = Join-Path $backupDir "export.json"
bw export --format json --output $backupFile

The JSON file doesn't include the attachments. Since I'm using them, I have to export those manually:

bw list items |
  ConvertFrom-Json |
  Where-Object { $_.attachments.Count -gt 0 } |
  ForEach-Object {
    $attachmentsDir = Join-Path $backupDir $_.id
    if (-not (Test-Path $attachmentsDir)) {
      New-Item -ItemType Directory -Path $attachmentsDir | Out-Null
    }
    foreach ($attachment in $_.attachments) {
      $attachmentFullPath = Join-Path $attachmentsDir $attachment.fileName
      bw get attachment $attachment.fileName --itemid $_.id --output $attachmentFullPath
    }
  }

To find the attachments, I list the items from the vault. I let PowerShell parse the returned JSON and then iterate through the items which have attachments. To be able to map those attachments back to the items, I store them in a separate directory for each item, using the item id as the directory name. After creating the directory, I iterate through the item attachments and download them keeping the attachment filename.

At the end of the script, I log out from the sessions to prevent any further access to the vault:

bw logout

The main restic backup script includes the $backupDir in the backup and deletes it afterwards to prevent further access to exported vault contents.

The backup gives me the peace of mind of having all the credentials securely stored and still available in the unlikely case that I couldn't access my Bitwarden vault anymore. Thanks to my restic backup policy, it also allows me to access any accidentally deleted items beyond the built-in vault trash functionality.

To impact the existing script as little as possible and keep the restic calls convenient without having to specify the password for every call, the above-mentioned newly created file is just another PowerShell script which sets the environment variable with the restic password:

$env:RESTIC_PASSWORD = 'my_restic_password'

To make the file only accessible with elevated privileges, I had to restrict its access to the Administrators (and SYSTEM) group. This can be achieved by following these steps:

• Open file Properties, navigate to Security tab and click Advanced.
• Click Disable inheritance and choose Convert inherited permissions into explicit permissions on this object in the next dialog.
• Remove current user from permission entries.
• Change owner to Administrators group.

After applying this configuration, you'll have to run your text editor as administrator if you want to make any further changes to the script.

To make the environment variable with the password available when running the backup script, I added the following call at the very beginning of it to invoke my new secure script containing the credentials:

. ./MySetEnvScript.ps1

Of course, this call will only succeed when the calling script is running with elevated privileges. Since my backup script is invoked from the Task Scheduler, I had to check Run with highest privileges on the General tab of the Properties window for the scheduled task to elevate its run-time privileges:

Doing this had the unfortunate side effect of making the mapped network drive with my restic repository inaccessible. To resolve the issue I had to map the drive in my new secure script which meant adding another password to it:

net use R: "\\server\share" "mySharePassword" /user:myShareUser

$env:RESTIC_PASSWORD = 'my_restic_password'
$env:RESTIC_REPOSITORY = "R:\"

With this change, the backup script worked again.

Of course, I couldn't make any restic calls from the command line anymore without entering the password every time. This was the end goal of the whole endeavor after all. Since this makes using restic really inconvenient, I now usually do that from an elevated terminal window. From it, I first invoke my secure script with the password the same way as from the backup script. From that point on, I can again use restic without having to manually enter the password. And once I'm done, I close the terminal window to avoid accidentally running any other commands in it.

When an existing user tried to login into Teams on a new device, they couldn't. However, Teams still worked fine on the old device where they logged in at an earlier point in time. Further investigation showed that the issue wasn't user-specific, the same happened to all users. This meant that the problem was organization-wide.

The issue was even more difficult to troubleshoot because there was no useful error message accompanying the failed login in Teams application. Fortunately it could easily be reproduced when trying to log into Teams from a private browser window. After logging in with a company Microsoft account, a page with a Sign in button showed up. Clicking the button didn't seem to do anything.

However, the browser developer tools provided more details. Each click resulted in a failed call to https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token. And the response body contained the following error message:

AADSTS500014: The service principal for resource 'https://api.spaces.skype.com' is disabled. This indicate that a subscription within the tenant has lapsed, or that the administrator for this tenant has disabled the application, preventing tokens from being issued for it.

This helped us discover that we weren't the only ones with this issue. And it identified the root cause of the error: the Microsoft Teams application has become disabled. Could we somehow reenable it?

It was time to take a closer look in the Microsoft Entra admin center. The Microsoft Teams app should be listed on the Enterprise apps page. It didn't look like it at first sight:

Removing the Application type == Enterprise Applications filter helped. Now, there were a lot of Microsoft Teams applications listed:

Microsoft Teams Services was the application I was looking for. On its Properties page I could see that it was Deactivated:

Toggling the Enabled for users to sign-in switch to Yes changed its Activation status to Activated. It was time try logging into Teams from a private browser window again. Unfortunately it still didn't work. But there was now a different error in the browser development tools:

AADSTS500014: The service principal for resource '00000003-0000-0ff1-ce00-000000000000' is disabled. This indicate that a subscription within the tenant has lapsed, or that the administrator for this tenant has disabled the application, preventing tokens from being issued for it.

Finding the right application in the Microsoft Entra Enterprise applications list was even easier this time. I could search by the Application ID value from the error message. It was the Office 365 SharePoint Service application and it was also Deactivated. I reactivated it the same way as Microsoft Teams. And I got yet another error when I tried to log in:

AADSTS7000112: Application 'a164aee5-7d0a-46bb-9404-37421d58bdf7'(Microsoft Teams AuthSvc) is disabled.

This time both the application Name and Application ID were listed in the error message. As if they were trying to make it easier for me. I reactivated Microsoft Teams AuthSvc just like the other two applications.

This finally fixed the issue for good. The login in the private browser window succeeded. I got a list of organizations I was added to. After choosing one of them I was logged into their Teams tenant. It worked from the Teams application as well. Let's just hope it stays that way.

And if not, I know what to check first. In the Microsoft Entra admin center the following Enterprise applications must be Activated (i.e., the Enabled for users to sign-in switch on the application Properties page must be set to Yes):

• Microsoft Teams Services, Application ID: cc15fd57-2c6c-4117-a88c-83b1d56b4bbe
• Office 365 SharePoint Online, Application ID: 00000003-0000-0ff1-ce00-000000000000
• Microsoft Teams AuthSvc, Application ID: a164aee5-7d0a-46bb-9404-37421d58bdf7

A server request filter is a method annotated with @ServerRequestFilter. To access a configuration property, inject it into is parent class:

public class Filters {
    @ConfigProperty(name="features.endpoints-enabled")
    boolean featureEndpointsEnabled;

    @ServerRequestFilter
    public RestResponse<?> featureFlagFilter(ContainerRequestContext requestContext) {
        if (!featureEndpointsEnabled &&
                !requestContext.getUriInfo().getPath().startsWith("/q/")) {
            return RestResponse.ResponseBuilder.notFound().build();
        }
        return null;
    }
}

When the method returns null, the processing will proceed, making the endpoint accessible. When the method returns a RestResponse, the processing stops and that response will be returned to the caller.

If you still want the Dev UI to work when you disable the endpoints, you need to check the requested path, and not block requests to paths which start with /q/.

To test the filter, you would need to change the value of a configuration property for the particular test. One way to do this is by using Quarkus test profiles. The test method must be placed in a separate test class which also acts as a test profile:

@QuarkusTest
@TestProfile(DisabledExampleResourceTest.class)
public class DisabledExampleResourceTest implements QuarkusTestProfile {

    @Override
    public Map<String, String> getConfigOverrides() {
        return Map.of(
                "features.endpoints-enabled", "false"
        );
    }

    @Test
    void testHelloEndpointDisabled() {
        given()
                .when().get("/hello")
                .then()
                .statusCode(404)
                .body(is(""));
    }
}

The getConfigOverrides method returns the key-value pairs of configuration properties to override.

You can find a sample project in my GitHub repository. It adds the filter to a new Quarkus project with a sample endpoint, and a test that validates its behavior.

Although request filters aren't all that flexible, they are a great fit for a functionality that affects all or many endpoints in the application.

To start with a clean slate, I first removed all the JDKs except the ones installed from IntelliJ IDEA. This included the ones listed in Windows Installed apps and those installed through vfox while I was testing it. I also made sure to delete the JAVA_HOME environment variable (at system and user level) and removed any Java related entries from the PATH environment variable (again at system and user level).

I then checked the JDKs I had installed in IntelliJ IDEA. To do that, I opened a Java project in IntelliJ IDEA, opened File > Project Structure... from the main menu and navigated to Platform Settings > SDKs. I selected each JDK in the list and copied the JDK home paths for future reference:

• openjdk-25: C:\Users\damir\.jdks\openjdk-25.0.1
• openjdk-23: C:\Users\damir\.jdks\openjdk-23.0.1

I decided to use JDK 25 by default, so I made the following changes to my user environment variables:

• I set JAVA_HOME to the JDK path: C:\Users\damir\.jdks\openjdk-25.0.1.
• I added the bin subfolder inside it to PATH: C:\Users\damir\.jdks\openjdk-25.0.1\bin.

This was enough to get Java 25 working in a newly opened terminal:

➜ java -version
openjdk version "25.0.1" 2025-10-21
OpenJDK Runtime Environment (build 25.0.1+8-27)
OpenJDK 64-Bit Server VM (build 25.0.1+8-27, mixed mode, sharing)

For switching to a different JDK version, I first created a generic PowerShell script that sets the JAVA_HOME and PATH variables correctly for a JDK in a given folder:

param(
  [Parameter(Mandatory)]
  [string]$Path
)

$env:JAVA_HOME = $Path
$env:Path = $env:JAVA_HOME + "\bin;" + $env:Path;

Two details worth mentioning:

• The environment variables are only changed for the given session. This allows me to use a different JDK version in each session.
• Having the bin subfolder added to the start of the PATH causes the files from this folder to be preferred over the ones from the default JDK, which is listed later in the path.

For convenience, I added the following two functions to my $PROFILE file:

Function Set-Jdk25
{
    Set-Jdk "C:\Users\damir\.jdks\openjdk-25.0.1"
}

Function Set-Jdk23
{
    Set-Jdk "C:\Users\damir\.jdks\openjdk-23.0.1"
}

Now I can use them to switch to a different JDK in the current session:

➜ Set-Jdk23
➜ java -version
openjdk version "23.0.1" 2024-10-15
OpenJDK Runtime Environment (build 23.0.1+11-39)
OpenJDK 64-Bit Server VM (build 23.0.1+11-39, mixed mode, sharing)

When I change the JDKs installed through IntelliJ IDEA, I only need to update the functions in my $PROFILE to match the set of installed JDKs and their paths. If I want to change the default JDK as well, I also need to update the JAVA_HOME and PATH environments accordingly.

The remote host may not meet VS Code Server's prerequisites for glibc and libstdc++ (The remote host does not meet the prerequisites for running VS Code Server)

The server did not meet the prerequisites, so I had to start looking for other solutions.

I decided to share the directory with the files I wanted to edit on the server so that I could access them from my computer. Using this approach, I managed to initialize a Git repository, but as soon as I wanted to perform any Git operation inside it, it failed with the following error:

fatal: detected dubious ownership in repository at '//my-server/my-share/my-dir'
'//my-server/my-share/my-dir' is owned by:
    (inconvertible) (S-1-5-21-577097838-3836064388-3576385918-3054)
but the current user is:
    MyWinPC/damir (S-1-5-21-804102101-2538954194-3365188178-1001)
To add an exception for this directory, call:

    git config --global --add safe.directory '%(prefix)///my-server/my-share/my-dir'

It was because of a security measure, introduced in Git 2.35.2. Changing the ownership of the files on the share wasn't an option, so I executed the command suggested in the error message to bypass the check for that specific directory:

git config --global --add safe.directory '%(prefix)///my-server/my-share/my-dir'

This has indeed resolved the issue, so that I could perform all Git operations as usual, both form command line and from GUI clients.

Before proceeding, I wanted to make sure that all the files would have Linux line endings although I would be editing them from Windows. In Visual Studio Code you can use the Change End of Line Sequence command to select the line endings for each file:

This works great for existing files, but there's always a risk of forgetting to switch the line endings when creating a new file. To avoid this, it's best to set the default value in workspace settings:

This setting will be persisted in .vscode/settings.json file, which can also be added to the git repository:

{
  "files.eol": "\n"
}

Git has its own approach to handling end of line differences between Windows and Linux in files committed to a Git repository. If you're working in Windows, you most likely have it enabled globally with the core.autocrlf setting set to true. In this particular scenario, this setting would interfere with using Linux line endings in Windows. To prevent that, the setting can be turned off locally for this repository by running the following command from any directory inside it:

git config core.autocrlf false

With all this configured, I could edit the files on the remote Linux server from Visual Studio Code in Windows and have the files versioned in a Git repository, although Visual Studio Code couldn't connect remotely to the server using SSH. The experience was still inferior, but it worked well enough for my particular use case.

During initial git setup you need to configure your name and email address to be used in git commits. Many graphical git clients provide user interface to do it, but you can also do it from command line:

git config --global user.name "Me"
git config --global user.email "email@primary.domain"

This configuration is saved to ~/.gitconfig in your home folder:

[user]
    name = Me
    email = email@primary.domain

By default, these settings are going to be used for all repositories you work with on your machine. You can however override any git configuration value for a specific repository. This includes your name and email. Some graphical git clients support this as well, but you can also do it by running the following commands from a folder inside that repository:

git config user.name "Me"
git config user.email "email@secondary.domain"

This configuration is saved to .git/config located at the repository root folder:

[user]
    name = Me
    email = email@secondary.domain

When alternative configuration is set for a repository like this, the name and email from it are going to be used for all commits to this repository.

Although this configuration process is simple enough, it doesn't scale well if your client uses microservices. It's too easy to forget changing the configuration for every single microservice repository you clone to your machine and start contributing to it. And in that case the wrong email from your default global configuration is going to be used.

Fortunately, you can use conditional includes to set the same configuration for all git repositories inside a specific parent folder. On my work machine, I already have all repositories for a certain client inside the same folder, so this matches well with my existing organization.

To use conditional includes, you first need to create a file with git configuration settings in standard format so that you can include it. I put it in the folder containing all the repositories from a specific client, but you could put it anywhere you like:

[user]
    name = Me
    email = email@secondary.domain

Then, you need to open your global git configuration file in ~/.gitconfig and conditionally include the configuration file you just created:

[includeIf "gitdir:~/Git/MyClient/"]
    path = ~/Git/MyClient/.gitconfig

If a repository matches the path after gitdir, the configuration file specified after path will be evaluated and will override any configuration values defined earlier in your global configuration file. If you're in a case-insensitive file system, you might want to use gitdir/i instead of gitdir to make the path comparison case-insensitive.

For now, I'm only using conditional includes for user and email configuration when I need to change it for all repositories of a certain client. But it's a very flexible tool in the toolbelt, so I might find another use for it in the future.