The adapter azure-storage-adapter throws type check error

[alexandrubau]

Following the official example from here you will encounter the following error:

Argument of type 'import("/<project_path>/node_modules/@azure/storage-blob/dist/commonjs/ContainerClient").ContainerClient' is not assignable to parameter of type 'import("/<project_path>/node_modules/@azure/storage-blob/dist/esm/ContainerClient", { with: { "resolution-mode": "import" } }).ContainerClient'.
  Types have separate declarations of a private property 'containerContext'.ts(2345)

To address this issue you need to type-cast using "any". Example:

import {BlobServiceClient} from '@azure/storage-blob';
import {FileStorage} from '@flystorage/file-storage';
import {AzureStorageBlobStorageAdapter} from '@flystorage/azure-storage-blob';

const blobService = BlobServiceClient.fromConnectionString(process.env.AZURE_DSN!);
const container = blobService.getContainerClient('flysystem');
const adapter = new AzureStorageBlobStorageAdapter(container as any); // <-- I've added "as any"
const storage = new FileStorage(adapter);

Here is my package.json version:

"@azure/storage-blob": "^12.28.0",
"@flystorage/azure-storage-blob": "^1.2.0",
"@flystorage/file-storage": "^1.2.0",

[frankdejonge]

Seems like there is a resolution difference between the commonjs and esm versins here, that's ... quite odd. Could you share your tsconfig.json? Perhaps that has some clues?

[alexandrubau]

I'm using Nest.js framework. Hope this helps.

// tsconfig.json
{
  "compilerOptions": {
    "module": "nodenext",
    "declaration": true,
    "removeComments": true,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "allowSyntheticDefaultImports": true,
    "target": "ES2023",
    "sourceMap": true,
    "outDir": "./dist",
    "baseUrl": "./",
    "incremental": true,
    "skipLibCheck": true,
    "strictNullChecks": false,
    "noImplicitAny": false,
    "strictBindCallApply": false,
    "forceConsistentCasingInFileNames": false,
    "noFallthroughCasesInSwitch": false,
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "paths": {
      // ...
    }
  }
}

[frankdejonge]

Do you have "type": "module" in your package.json?

[alexandrubau]

Here is my package.json file. As you can see there is no "type": "module".

// package.json
{
  "name": "my-project",
  "version": "0.0.1",
  "description": "",
  "author": "",
  "private": true,
  "license": "UNLICENSED",
  "scripts": {
    // ...
  },
  "dependencies": {
    // ...
  },
  "devDependencies": {
    // ...
  },
  "jest": {
    // ...
  }
}

[frankdejonge]

@alexandrubau looked into this a bit more, but could it be that the combination of having a CJS project + setting the tsconfig module option to nodenext is the problem? From what I understand, that resolution strategy supports imports and require, where this particular import is done using a resolution-mode of import.

[frankdejonge]

I believe to have found the issue. Working on a fix.