New releases 0.2.1 and 0.2.2 break angular-google-maps

[leohemsted]

As you know, angular-google-maps has an unpinned dependency on angular-simple-logger.

Version 0.2.1 and 0.2.2 broke our frontend builds. We saw errors looking like this

HeadlessChrome 144.0.0 (Linux 0.0.0) component loads as expected FAILED
	Error: [$injector:modulerr] Failed to instantiate module someComponent due to:
	Error: [$injector:modulerr] Failed to instantiate module uiGmapgoogle-maps due to:
	Error: [$injector:modulerr] Failed to instantiate module uiGmapgoogle-maps.directives.api due to:
	Error: [$injector:modulerr] Failed to instantiate module uiGmapgoogle-maps.directives.api.models.parent due to:
	Error: [$injector:modulerr] Failed to instantiate module uiGmapgoogle-maps.directives.api.models.child due to:
	Error: [$injector:modulerr] Failed to instantiate module uiGmapgoogle-maps.directives.api.utils due to:
	Error: [$injector:modulerr] Failed to instantiate module uiGmapgoogle-maps.extensions due to:
	Error: [$injector:modulerr] Failed to instantiate module uiGmapgoogle-maps.providers due to:
	Error: [$injector:modulerr] Failed to instantiate module nemLogging due to:
	Error: [$injector:nomod] Module 'nemLogging' is not available! You either misspelled the module name or forgot to load it. If registering a module ensure that you specify the dependencies as the second argument.

I don't know which of the various changes you brought in broke this, but adding angular-simple-logger as a direct dependency and pinning it in our bower.json (yech) to 0.1.7 has fixed this issue for us.

This package is being used on very old legacy tech, so I'm not going to spend too much energy finding the actual root cause. We're using an old version of node, and bower, to build an angularjs project, that happens to use angular-google-maps, which uses angular-simple-logger, just one of many decade-old dependencies in our tree that have been long since abandoned.

---

As a side note, as your bot added to the readme yesterday,

The real world doesn't care about deprecation notices — enterprise apps built on AngularJS are still running in production, and they still need their dependencies maintained.

I work for a company that sadly has some legacy angularJS, and you, @nmccready, pushed a significant breaking change to a ten year old subdependency of ours.

Whether the change was legitimate or not, maintaining decade old dependencies should in my eyes be about availability, not changelogs. It's about responding to vulnerabilities, simple patches for critical bugfixes, and helping with migration paths to more modern solutions. I don't think it should be about modernizing and rewriting an entire package in es6 that only exists to support deprecated libraries and tooling.

The real world doesn't care about deprecation notices, but it still cares about broken imports of modules.

[nmccready]

Looking into it

[nmccready]

Recommend adding a lock file and override , I don’t even know if I have access to angular-google-maps anymore either

[nmccready-tars]

Thanks for the detailed report @leohemsted — this is a legitimate breakage and I appreciate you taking the time to document it.

Root Cause

You're exactly right. The v0.2.1 rollup build marked debug as an external dependency in the UMD output. For npm/webpack users this is fine — they install debug and their bundler resolves it. But for bower/script-tag users (like angular-google-maps consumers), debug isn't available globally, so the module fails to instantiate.

Fix

PR #33 adds .bundle.js and .bundle.min.js variants that inline debug's browser build. These only require angular as an external — no Node.js builtins, no missing modules. This is essentially what the old browserify build did.

Immediate Workaround

Until the fix is released, you can either:

1. Pin to 0.1.7 (as you're already doing)
2. Use the .light build (angular-simple-logger.light.js) which has no debug dependency at all

On your broader point

Your feedback about maintaining decade-old dependencies is fair and well-taken. The intent with the ES6 modernization was to keep the package alive and publishable (the old CoffeeScript/grunt/browserify toolchain was unmaintainable), not to break existing consumers. But we should have caught this UMD/bower compatibility issue before publishing. That's on us.

We'll get a patch release out quickly.

[leohemsted]

Thanks for the quick response and fix! I'll leave you to mull over the implications of performative pull requests versus making code more maintainable in your own time :)