firebase-functions: Unable to import https.HttpsError class

Related issues

Could not find this specific issue linked.

[REQUIRED] Version info

node: v14.17.1

firebase-functions: v3.15.1

firebase-tools: v9.16.1

firebase-admin: v9.11.0

typescript v3.8.3

[REQUIRED] Test case

// index.ts

import * as functions from 'firebase-functions';

function example() {
  throw new functions.https.HttpsError('example-reason', 'example-message');
}

The above example will fail

[REQUIRED] Steps to reproduce

Attempt to build/run the above example using standard tsconfig.json from the Firebase Functions example repository.

[REQUIRED] Expected behavior

The above code will compile, instantiate an HttpsError class, and throw it.

[REQUIRED] Actual behavior

Fails with the following message:

src/helpers/common.ts:7:31 - error TS2339: Property 'HttpsError' does not exist on type 'typeof import("/Users/path/to/project/functions/node_modules/firebase-functions/lib/v1/providers/https")'.

It appears that only the type declaration is exported, and not the class itself.

Attempting to import the HttpsError class directly, e.g.:

import { HttpsError } from 'firebase-functions/lib/common/providers/https';

Causes the following error during the parsing your function triggers stage of deployment:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/common/providers/https' is not defined by "exports" in /home/runner/work/firebase-fns/firebase-fns/functions/node_modules/firebase-functions/package.json

Were you able to successfully deploy your functions?

Not able to successfully deploy: see above.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 33
  • Comments: 46 (9 by maintainers)

Most upvoted comments

FYI this broke our production app when we redeployed a minor change. Not impressed at introducing this breaking change in a minor / patch version.

firebase-functions-test@0.3.2 should fix the issue.

Hi folks, sorry to see all the trouble the new releases of firebase-functions and firebase-tools are causing. We did change the directory structure of firebase-functions and there are clearly gaps between our testing and real-world usage.

We are working to quickly bring out a new release that fixes the issues you’re experiencing, but until then we recommend reverting to firebase-functions@3.14.1 and firebase-tools@9.16.0.

I agree with @studds. My app also broke with this update. This is not the first time an update broke basic functionality.

It seems like updating is a very dangerous operation with Firebase lately. Definitely going to be holding back longer on any updates in the future. Please improve the testing @firebase!

Firebase why you do this to me? 😿

Still having this issue with v4.0.2

@inlined Thanks, I’m not using it based on your advice.

This update does fix the errors, above, however, it does not work with 0.3.1 of firebase-functions-test

When executing

import * as firebaseFunctionsTest from 'firebase-functions-test';
export const test = firebaseFunctionsTest({});

the following error is thrown:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/encoder' is not defined by "exports" in /Users/mquinlan/work/projects/pretzel/delivery/functions/node_modules/firebase-functions/package.json
    at throwExportsNotFound (internal/modules/esm/resolve.js:285:9)
    at packageExportsResolve (internal/modules/esm/resolve.js:508:3)
    at resolveExports (internal/modules/cjs/loader.js:424:36)
    at Function.Module._findPath (internal/modules/cjs/loader.js:464:31)
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:802:27)
    at Function.Module._load (internal/modules/cjs/loader.js:667:27)
    at Module.require (internal/modules/cjs/loader.js:887:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/Users/mquinlan/work/projects/pretzel/delivery/functions/node_modules/firebase-functions-test/lib/providers/firestore.js:26:19)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:702:16)
    at Module.require (internal/modules/cjs/loader.js:887:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/Users/mquinlan/work/projects/pretzel/delivery/functions/node_modules/firebase-functions-test/lib/features.js:8:19)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:702:16)
    at Module.require (internal/modules/cjs/loader.js:887:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at module.exports (/Users/mquinlan/work/projects/pretzel/delivery/functions/node_modules/firebase-functions-test/lib/index.js:30:20)

Yes, throw new functions.https.HttpsError('invalid-argument', 'foo') is absolutely defined behavior that was accidentally broken. Fix is upcoming. The intentional break that we’re temporarily backtracking on is import { HttpsError } from 'firebase-functions/lib/providers/https'

Hi @inlined

just in case it’s unclear, this broke for typescript projects using the widely documented examples of throwing errors.

I don’t import those as others are referencing.

throw new functions.https.HttpsError('invalid-argument', 'The function must be called with ' +
        'one arguments "text" containing the message text to add.');

We have released new versions of both libraries that should address this. Please try firebase-functions@3.15.2 and firebase-tools@9.16.3 and let me know if you are still experiencing issues.

Hi, I can still reproduce this on 3.15.2.

Downgrading back to ^3.14.1 works (had to undo changes to lock files).

Use import { HttpsError } from "firebase-functions/lib/common/providers/https";

I was still getting this with the current versions (3.15.7 and 9.20.0), and it turned out it was because I was using regionalised versions of functions, and this apparently doesn’t support HttpsError:

const functions = require('firebase-functions').region(myRegion)

exports = module.exports = functions.https.onCall(async (data, context) => {
  throw new functions.https.HttpsError('permission-denied', 'Not for you')  // This results in Unhandled error TypeError: HttpsError is not a constructor
})

Note this did work in versions prior to the update mentioned in this thread. Now, using this works fine:

let functions = require('firebase-functions')
const HttpsError = functions.https.HttpsError
functions = functions.region(myRegion)

exports = module.exports = functions.https.onCall(async (data, context) => {
  throw new HttpsError('permission-denied', 'Not for you')  // Works fine now
})

Even though the region() method returns a FunctionBuilder, it doesn’t appear to include all the required properties to access the error constructor.

I have the same problem with export. Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/encoder' is not defined by "exports" in /.../firebase/functions/node_modules/firebase-functions/package.json

@all firebase-functions 3.15.3 should address the issues in this thread, so I’ll close it.

@mikquinlan The v2 SDK is definitely not ready for public use. Stick with v1 for now unless you join the alpha testers group and get instructions for using the v2 SDK.

@mikquinlan, @efstathiosntonas, & @leon We were of the stance that we could/should break imports of every lib/ except for lib/logger and lib/logger/compat because they were never documented and thus not part of a public API surface. #948 is going to fix this for you for now but we’re definitely ripping out all /lib paths in the next major release. We’ve provided v2-like options where you can now import v1/https instead of lib/providers/https, but I’m not even sure we really want to keep those. The v1 APIs weren’t designed to be deep-imported unlike v2. Speaking of which, v2 is coming but isn’t ready yet. If you want to provide feedback, make sure you’re in our alpha group. I’m particularly interested in hearing from users like you who want to do deep-imports.

@drcampbell Node 10 is still supported for now, though the writing is on the wall. I’d recommend upgrading to a version of Node that is still supported by the community & getting security patches.

@johnnyoshika Looking into your error. We’ll get it fixed.