Fix ng build warnings

[1001daysofcode]

There are several warnings

[ethaneckstein]

Its a waste of time. No one even looks at these issues.

[armando-navarro]

@1001daysofcode Thanks for the report, and apologies that it sat unanswered this long.

I tried to reproduce this from the screenshot, and I want to share what I found. I may be missing something about your project, and I'd like your help confirming or refuting this before anything is decided.

What I tried

• A fresh Angular app using the webpack browser builder
• File layout mirroring the paths in your screenshot:
  • *-private.resolve.ts files
  • theme.stubs.ts
  • the environment.alpha/beta/production.ts trio
  • src/test.ts
  • theme.service.ts that imports the color package
• Building that app before adding AngularFire at all produced what appears to be the same warning set as your screenshot.
• Adding @angular/fire to the same app didn't add or change any warning.

My working theory

So my working theory is that these warnings aren't coming from AngularFire:

• The …is part of the TypeScript compilation but it's unused warnings come from the Angular CLI's webpack builder: any .ts file matched by tsconfig.app.json's include (the default src/**/*.ts) that isn't reachable from an entry point gets flagged.
  • Your environment.*.ts replacement files and src/test.ts are exactly this case: matched by include, but not reached from an entry point (see e.g. angular/angular-cli#17485).
  • Narrowing files/include in tsconfig.app.json silences it.
• The theme.service.ts depends on 'color' warning is about the color npm package being CommonJS (its v4 line; v5 is ESM).
  • Adding color to allowedCommonJsDependencies in angular.json, or upgrading to color@5, addresses that one.

Background (if the theory holds)

• Both warnings come from the Angular CLI's webpack builder (angular/angular-cli repo), not from anything in your dependency list, and both look like intended diagnostics rather than bugs.
  • On the unused-file warning, the CLI maintainers have pointed reporters at their tsconfig files/include rather than treating it as a CLI defect.
  • See angular/angular-cli#17485, where the resolution was to narrow tsconfig.app.json to entry points, matching the shape the CLI's own generated template uses.
• On the color side, the maintainers resolved this on their end by shipping v5 as native ESM.
• The webpack browser builder is deprecated (per Angular's build-system docs), and the newer esbuild application builder that replaced it simply doesn't perform this unused-file analysis, so the warning doesn't occur there.

Concrete fixes for your project

• For the unused-file warnings: change tsconfig.app.json to "files": ["src/main.ts"] plus "include": ["src/**/*.d.ts"].
  • In my reproduction this took the unused-file warning count to zero, with AngularFire installed and fileReplacements still working (the color warning is separate; see below).
  • Alternatively, keep the broad include and delete or wire up the files nothing reaches.
• For the color warning: upgrade to color@5, which ends the warning at the source.
  • allowedCommonJsDependencies in angular.json is the way to acknowledge it deliberately if you need to stay on v4.
• Longer-term: migrating to the application builder is the durable path (the tweaks above work without it).

What would help me verify

I'd prefer to gather more information before committing to these conclusions. A few things would help me verify:

1. Which versions are you on: ng version output, and the @angular/fire entry in your package.json?
2. Is there more build output below the screenshot's last line, in particular anything that mentions @angular/fire or firebase?
3. Could you paste your tsconfig.app.json (especially files/include/exclude)?
4. Did the warnings start after a particular upgrade or after ng add @angular/fire, or have they always been there?

One more AngularFire-side detail

• Old versions (≤ 7.x) of ng add @angular/fire did create environment.*.ts files, so if this project goes back that far, some of the flagged files may originally have been generated by AngularFire.
• The warning itself is still the tsconfig-include behavior above, but I mention it in case it explains where those files came from.

If your provided details point somewhere I've missed, I'll dig back in.

[google-oss-bot]

Hey @1001daysofcode. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Hey @1001daysofcode. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Hey @1001daysofcode. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[google-oss-bot]

Hey @1001daysofcode. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!

[1001daysofcode]

I removed angularfire and just used the sdk instead

[google-oss-bot]

Hey @1001daysofcode. We need more information to resolve this issue but there hasn't been an update in 7 weekdays. I'm marking the issue as stale and if there are no new updates in the next 7 days I will close it automatically.

If you have more information that will help us get to the bottom of this, just add a comment!