Missing dependency causes installation error on Firebase

[dackers86]

When installing any extension on Firebase using the command firebase ext:install . --project=my-test-project.

I receive the error....

ext-shipengine-validate-address-5f7z-validateAddress
{"@type":"type.googleapis.com/google.cloud.audit.AuditLog","status":{"code":3,"message":"Build failed: npm ERR! code ENOVERSIONS\nnpm ERR! No valid versions available for shipengine-firebase-common\n\nnpm ERR! A complete log of this run can be found in:\nnpm ERR! /www-data-home/.npm/_logs/2021-09-23T09_09_22_506Z-debug.log; Error ID: b0ba1f57"},"authenticationInfo":{"principalEmail":"219368645393@cloudservices.gserviceaccount.com"},"serviceName":"cloudfunctions.googleapis.com","methodName":"google.cloud.functions.v1.CloudFunctionsService.CreateFunction","resourceName":"projects/extensions-testing/locations/europe-west2/functions/ext-shipengine-validate-address-5f7z-validateAddress"}

From the error message it appears that the dependency "shipengine-firebase-common": "1.0.0", is unavailable, could this be made available for external builds?

[andyhite]

@dackers86 I was under the impression that the "prepare" script you recommended (https://github.com/ShipEngine/firebase-extensions/pull/13) would handle the build process for workspace libs so it didn't need to be published specifically to npm. The shipengine-firebase-common library is located in the libs directory of the firebase-extensions project and is included in the dependencies through the yarn workspaces support.

I can re-publish the shipengine-firebase-common library if the "prepare" script does not actually work with this scenario.

[dackers86]

Hi @andyhite. It is my understanding the Firebase installations will only use files located in the src folder and node_modules to build the extension. At runtime it would be unable to to find local folders or workspaces within the project, such as the common directory.

A possible solution could be to publish common to npm as a package.

[andyhite]

@dackers86 I think we just misunderstood what that prepare PR was supposed to do (and I haven't tried installing since we merged that). I had previously published the common package, but unpublished it when we merged the prepare PR. I'll go ahead and re-publish and let you know when that's done.

[andyhite]

@dackers86 published. I had to bump the version of the lib, so go ahead and pull before you try installing again.

[dackers86]

Thanks @andyhite

[dackers86]

@andyhite Have you encountered the issue when building locally...

shipengine-firebase-extensions@workspace:. couldn't be built successfully (exit code 1)

No error logs appear, but i'm troubling building the solution. This occurs on both master and development branches.

[andyhite]

@dackers86 I'll take a look when I'm out of my current meeting. The last time I looked at it, it was successfully building.

[Salakar]

Just tried to look at this with @dackers86 - it seems like maybe there's an issue with the common package that is currently published on NPM here: https://www.npmjs.com/package/shipengine-firebase-common

It shows that v1.1.0 on the latest tag is available and public - but when trying to deploy any of the extensions that use this package and v1.1.0 it fails with:

✖ Installing your extension instance. This usually takes 3 to 5 minutes...

Error: ; RESOURCE_ERROR at /deployments/firebase-ext-shipengine-validate-address-
yg4s/resources/validateAddress: {"ResourceType":"gcp-types/cloudfunctions-
v1:projects.locations.functions","ResourceErrorCode":"400","ResourceErrorMessage":"Build failed: npm 
ERR! code ENOVERSIONS\nnpm ERR! No valid versions available for shipengine-firebase-common\n\nnpm 
ERR! A complete log of this run can be found in:\nnpm ERR!     /www-data-home/.npm/_logs/2021-09-
29T17_32_54_376Z-debug.log; Error ID: b0ba1f57"}

Digging further, we tried just installing the common package into a fresh npm init project via npm i shipengine-firebase-common - this also fails similarly:

npm ERR! code ENOVERSIONS
npm ERR! No versions available for shipengine-firebase-common

Either something is up with the package on NPM or we may be missing something?

---

Also, I think common is missing a dependency on lodash since it uses it here: https://github.com/ShipEngine/firebase-extensions/blob/master/libs/common/src/logger/console-logger.ts#L2 - but is not added as a dependency in the package.json file - but I guess this may not be a massive issue since it's used in testing only so it's probably pulling in lodash transitively from another dependency in the workspace

[andyhite]

@Salakar @dackers86 I think I've got this worked out. I'm thinking that when I unpublished the package originally it somehow screwed something up. Should have some code pushed in just a bit that fixes this (needed to rename the lib to publish it as a new package).

[andyhite]

@Salakar @dackers86 okay, pull master or development now and give it another shot.

[Salakar]

@andyhite seems promising now - but I think there's another issue now in all the extensions that have src/test directories;

track-label-functions@undefined prepare /workspace\n> npm run build\n\n\n> track-label-functions@
 build /workspace\n> tsc --build\n\nsrc/test/trackLabel.spec.ts(2,32): error TS7016: Could not find a 
declaration file for module 'chai'. '/workspace/node_modules/chai/index.js' implicitly has an 'any' 
type.\n  Try `npm install @types/chai` 

Since the current tsconfig includes all of src and the package.json has a prepare script this prepare script is ran when the extension builds on GCP - however GCP extension builder runs npm ci which will only install dependencies but @types/chai is only in dev dependencies - hence the error that says it's missing types when trying to tsc - we worked around this by locally updating tsconfig in each extension to exclude: ["src/test"] - this allows us to install the extensions fine but will break local testing - alternatively can leave config as is but move @types/* into deps to get around it.

---

There's an example PR here: https://github.com/ShipEngine/firebase-extensions/pull/23

[andyhite]

I'm pushing a fix for this now.

[andyhite]

Fix merged to development branch, as was the adjustment to the default key that track-label is looking for.