fulls1z3/ngx-config

Configuration utility for Angular

ngx-config's Issues

need event/promise when config is loaded

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior
Checking of configService.getSettings() !== udnefined is currenltly way to know when config is loaded

Expected/desired behavior
Emit event (or expose promise) when config is loaded

What is the motivation / use case for changing the behavior?
For example, I need call API to get permissions for user and I want to do it before application starts,
so I'm using APP_INITIALIZER also.
But I want to keep this API endpoint in config:

{ provide: APP_INITIALIZER, useFactory: getPermissions, deps: [Injector], multi: true },

export function getPermissions(injector: Injector) {
    return async () => {
        const configService = injector.get(ConfigService);
        await whenConfigInitialized(configService); // ?
    };
}

Is this chicken egg or dead lock situation?
For staticLoader promise will be resolved on next tick, so I can workaround it as setTimeout(..., 0)
But this is not work for httpLoader.

Environment

• Angular version: 4.4.7

allow returning promise

**I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior

1. Using an Angular app (v. 5.2.6), import the following into app.module:

ConfigModule.forRoot({
  deps: [HttpClient],
  provide: ConfigLoader,
  useFactory: configFactory,
}),

where configFactory is:

export function configFactory(http: HttpClient): ConfigLoader {
  return new ConfigHttpLoader(http)
}

Then use getSettings in a service:

@Injectable()
export class MyService {
  constructor(private configService: ConfigService) {
    const url = configService.getSettings("api.url", "")
  }
}

url would always be empty string, when in my config.json file was this:

{
  "api": {
    "url": "www.example.com/api"
  }
}

This is mainly because the HttpLoader is most likely not finished with getting config.json by the time the constructor in my service calls getSettings.

Expected/desired behavior
Same code, except have two methods: getSettingsSync and getSettings, where getSettings returns a Promise or Observable when the service is finished with getting the settings.

Then in my code, I would go back to MyService and do this:

constructor(private configService: ConfigService) {
  const url = await configService.getSettings("api.url")
}

What is the motivation / use case for changing the behavior?
It is nice to have the getSettings method to always return your expected configuration. Since it didn't do this, it took me about 2-4 hours to realize why.

Environment

• Angular version: 5.2.6

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

does http loader still work with an XHR JSON response?

I'm submitting a ... (check one with "x")

[X] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[X] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior

Previously we were using ngx-config/http-loader with Angular 5. We upgraded to Angular 6 and ngx-config to 6 as well. Now ngx-config does not load the JSON into the settings object. Instead, it copies the full HTTP response into settings.

Does http loader still work with an XHR JSON response? It used to.

rxjs subscribe deprecated - will be removed in v8

rxjs subscribe is deprecated and will be removed in v8, use separate callback arguments.

http-loader\config.http-loader.ts
  15:31  warning  'subscribe' is deprecated. Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-arguments  deprecation/deprecation

merge-loader\config.merge-loader.ts
  51:10  warning  'subscribe' is deprecated. Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-arguments  deprecation/deprecation

Further deprecation: throwError
merge-loader\config.merge-loader.ts
https://rxjs.dev/6-to-7-change-summary#throwerror

add configPipe

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

Current behavior

Expected/desired behavior
use features from @unlight 's fork

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

angular-cli + universal compliance

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior
@bliitzkrieg explained at fulls1z3/ngx-meta#56

Expected/desired behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

• Angular version: X.Y.Z

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

testing issue with config.json

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[X] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior

I started testing components on my app but i got stucked with the @ngx-config loading.

app.module.ts

    export function configFactory(http: Http): ConfigLoader {
      return new ConfigHttpLoader(http, './assets/config.json'); // API ENDPOINT
    }

    [...]

app.component.ts

    constructor(private translateService: TranslateService, authService: AuthService,
        router: Router, rideService: RideService, appConfigService: AppConfigService, infoService: InfoService) {
    
        this.feVersion = appConfigService.FEVersion;
        this.beVersion = infoService.getBEVersion();

    [...]

appConfig.service.ts

    @Injectable()
    export class AppConfigService {
    
      constructor(private configService: ConfigService) { }
    
    get FEVersion(): string {
        return _.defaultTo(this.configService.getSettings('svnRevision'), '');
      }

app.component.spec.ts

    describe('AppComponent', () => {
    
      beforeEach(async(() => {
        TestBed.configureTestingModule({
          declarations: [
            AppComponent,
            [...lot of other components...]
          ],
          imports: [
            [...lot of modules...],
            ConfigModule.forRoot({
              provide: ConfigLoader,
              useFactory: (configFactory),
              deps: [Http]
            })
          ],
          providers: [
            { provide: APP_BASE_HREF, useValue: '/' },
            AppConfigService,
            {
              provide: LAZY_MAPS_API_CONFIG,
              useClass: MapsConfig,
              deps: [HttpClient]
            },
            AuthService,
            AuthGuard,
            ResearchService,
            RideService,
            GeoService,
            MailService,
            ConfirmationService,
            MessageService,
            VehicleService,
            InfoService,
            AuthRequestInterceptorProvider()
          ]
        }).compileComponents();
      }));
    
      it('should create the app', async(() => {
        const fixture = TestBed.createComponent(AppComponent);
        const app = fixture.debugElement.componentInstance;
        expect(app).toBeTruthy();
      }));
    });

config.json

    {
        "svnRevision": "412",
        [...]
    }

ERROR:

    Failed: No setting found with the specified key [svnRevision]!
    Error: No setting found with the specified key [svnRevision]!
        at ConfigService.webpackJsonp../node_modules/@ngx-config/core/@ngx-config/core.es5.js.ConfigService.getSettings node_modules/@ngx-config/core/@ngx-config/core.es5.js:38:1)
        at AppConfigService.get [as FEVersion] src/app/services/appConfig.service.ts:20:43)
        at new AppComponent src/app/app.component.ts:40:39)
        at createClass node_modules/@angular/core/esm5/core.js:12449:1)
        at createDirectiveInstance node_modules/@angular/core/esm5/core.js:12284:22)
        at createViewNodes node_modules/@angular/core/esm5/core.js:13742:38)
        at createRootView node_modules/@angular/core/esm5/core.js:13631:1)
        at callWithDebugContext node_modules/@angular/core/esm5/core.js:15056:26)
        at Object.debugCreateRootView [as createRootView] node_modules/@angular/core/esm5/core.js:14339:1)
        at ComponentFactory_.webpackJsonp../node_modules/@angular/core/esm5/core.js.ComponentFactory_.create node_modules/@angular/core/esm5/core.js:11236:26)

I can see on the devTools network tab that the config.json has has been loaded, so it's not a matter of karma not finding it or whatever.
It seems like the configService doesn't know where is the config.json.

Expected/desired behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

• Angular version: 5.2.X

• Browser:

• Chrome (desktop) version 66.0.3359
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: 8.9.1
• Platform: Windows

• Others:

token replacement on paths (ConfigMergedHttpLoader)

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

As mentioned in #4, @zjx20:
Now, we have such an use case, and I would like to listen to your ideas:

• Let's say we have two config files: config.local.json, and http://some-api-provider.com/api/get-settings.
• We pass these locations to the paths property of ConfigMergedHttpLoader.
• We want ConfigService processes those two config files sequentally, and replace the API URL some-api-provider with a value from config.local.json.

In other words:

config.local.json

{
  "api-endpoint": "http://some-api-provider/api"
}

app.module

const configFactory(http: Http): ConfigLoader {
  return new ConfigMergedHttpLoader(http, ['./config.local.json', '{{api-endpoint}}/get-settings'])
}

Version for angular 10

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ X] Feature request
[ ] Documentation issue or request

Support for Angular 12

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ x] Feature request
[ ] Documentation issue or request

Current behavior

Building the application fails with the following errors:

Error: node_modules/@ngx-config/core/config.module.d.ts:14:21 - error TS2694: Namespace '"****/node_modules/@angular/core/core"' has no exported member 'ɵɵNgModuleDefWithMeta'.

14 static ɵmod: i0.ɵɵNgModuleDefWithMeta<ConfigModule, [typeof i1.ConfigPipe], never, [typeof i1.ConfigPipe]>;
~~~~~~~~~~~~~~~~~~~~~

Error: node_modules/@ngx-config/core/config.pipe.d.ts:8:21 - error TS2694: Namespace '"****/node_modules/@angular/core/core"' has no exported member 'ɵɵFactoryDef'.

8 static ɵfac: i0.ɵɵFactoryDef<ConfigPipe, never>;
~~~~~~~~~~~~

Error: node_modules/@ngx-config/core/config.pipe.d.ts:9:22 - error TS2694: Namespace '"****/node_modules/@angular/core/core"' has no exported member 'ɵɵPipeDefWithMeta'.

9 static ɵpipe: i0.ɵɵPipeDefWithMeta<ConfigPipe, "config">;
~~~~~~~~~~~~~~~~~

Error: node_modules/@ngx-config/core/config.pipe.d.ts:10:22 - error TS2724: '"****/node_modules/@angular/core/core"' has no exported member named 'ɵɵInjectableDef'. Did you mean 'ɵgetInjectableDef'?

10 static ɵprov: i0.ɵɵInjectableDef;
~~~~~~~~~~~~~~~

Error: node_modules/@ngx-config/core/config.service.d.ts:9:21 - error TS2694: Namespace '"****/node_modules/@angular/core/core"' has no exported member 'ɵɵFactoryDef'.

9 static ɵfac: i0.ɵɵFactoryDef<ConfigService, never>;
~~~~~~~~~~~~

Error: node_modules/@ngx-config/core/config.service.d.ts:10:22 - error TS2724: '"****/node_modules/@angular/core/core"' has no exported member named 'ɵɵInjectableDef'. Did you mean 'ɵgetInjectableDef'?

10 static ɵprov: i0.ɵɵInjectableDef;
~~~~~~~~~~~~~~~

Expected/desired behavior

It compiles withour errors!

What is the motivation / use case for changing the behavior?

To be able to use ngx-config with the most recent angular version

Environment

• Angular version: 12.0.2

For Tooling issues:

• Node version: v14.17.0
• Platform: Mac

• Others:

allow for error page when promise is unreachable

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior
@mattfirtion

`http-loader` should be configurable to allow for custom behavior when the endpoint is unreachable.

Expected/desired behavior
http-loader should be configurable to allow for custom behavior when the endpoint is unreachable. i.e. route to an error page, or use the static loader.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?
The application fails to load with no indication to the user as to why.

Environment

• Angular version: 4.0.x

• Browser:

• Chrome (desktop) version 57
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

provide unit tests and coverage for `fs-loader`

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior

Expected/desired behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

• Angular version: X.Y.Z

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

module resolution error during AoT compilation

I'm submitting a ... (check one with "x")

[x] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior
As described on fulls1z3/ngx-meta#81

Expected/desired behavior
The compilation should succeed on AoT.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

• Angular version: ALL

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

add `suppressErrors` param to ConfigLoader

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

As discussed on https://github.com/ngx-config/merge-loader/issues/3

option to use an imported configuration file

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[x] feature request

Current behavior
Only works with http loaded config file

Expected/desired behavior
Provide the option to load an imported config file for compile time loading.

What is the motivation / use case for changing the behavior?
Better performance and security.

caching issues

how to avoid caching of the data. If there is changes in the config.json file from the server, the changes are not reflected. Only after a cache is deleted from the browser it takes the new changes. How can we avoid the caching issues?

sample karma test of app that uses ngx-config

I'm submitting a
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[ x] Support request =>
[ ] Feature request
[x] Documentation issue or request

I require a sample karma test of an app that uses ngx-config, so i may follow how to create a karma test spec of an angular app that uses ngx-config

use compodoc to generate project docs

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior

Expected/desired behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

• Angular version: X.Y.Z

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

fs-loader gives error: `NodeInvocationException: n.i(...) is not a function`

I'm using Angular 4 Universal with .net core 2 (vs 2017 core 2 template)
I have installed:
"@ngx-config/core": "^0.2.0-rc.5",
"@ngx-config/fs-loader": "^0.2.0-beta.1",

my setup:
`export function configFactory(): ConfigLoader {
return new ConfigFsLoader('./ng-app-settings.json'); // FILE PATH
}
imports: [

ConfigModule.forRoot({
  provide: ConfigLoader,
  useFactory: (configFactory)
}),

`
and I get an error at run time:

NodeInvocationException: n.i(...) is not a function
TypeError: n.i(...) is not a function
at t.loadSettings (\ClientApp\dist\main-server.js:18307:931)
at t.init (C:\projects\stash\liveflo\liveflo.spa\src\XpertHR.Liveflo.SPA\ClientApp\dist\main-server.js:11120:1234)

my package.json

{ "name": "xperthrliveflospa", "private": true, "version": "0.0.0", "scripts": { "test": "karma start ClientApp/test/karma.conf.js" }, "dependencies": { "@angular/animations": "4.2.5", "@angular/common": "4.2.5", "@angular/compiler": "4.2.5", "@angular/compiler-cli": "4.2.5", "@angular/core": "4.2.5", "@angular/forms": "4.2.5", "@angular/http": "4.2.5", "@angular/platform-browser": "4.2.5", "@angular/platform-browser-dynamic": "4.2.5", "@angular/platform-server": "4.2.5", "@angular/router": "4.2.5", "@ngrx/core": "^1.2.0", "@ngrx/effects": "^2.0.4", "@ngrx/store": "^2.2.3", "@ngrx/store-devtools": "^3.2.4", "@ngtools/webpack": "1.5.0", "@ngx-config/core": "^0.2.0-rc.5", "@ngx-config/fs-loader": "^0.2.0-beta.1", "@ngx-config/http-loader": "^0.2.0-rc.1", "@types/webpack-env": "1.13.0", "angular2-template-loader": "0.6.2", "aspnet-prerendering": "^3.0.1", "aspnet-webpack": "^2.0.1", "awesome-typescript-loader": "3.2.1", "bootstrap": "3.3.7", "css": "2.2.1", "css-loader": "0.28.4", "es6-shim": "0.35.3", "event-source-polyfill": "0.0.9", "expose-loader": "0.7.3", "file-loader": "0.11.2", "file-system": "^2.2.2", "html-loader": "0.4.5", "intl": "^1.2.5", "isomorphic-fetch": "2.2.1", "jquery": "3.2.1", "json-loader": "0.5.4", "preboot": "4.5.2", "raw-loader": "0.5.1", "reflect-metadata": "0.1.10", "rxjs": "5.4.2", "style-loader": "0.18.2", "to-string-loader": "1.1.5", "typescript": "2.4.1", "url-loader": "0.5.9", "webpack-hot-middleware": "2.18.2", "webpack-merge": "4.1.0", "zone.js": "0.8.12" }, "devDependencies": { "@types/chai": "4.0.1", "@types/jasmine": "2.5.53", "@types/jquery": "^3.2.11", "@types/node": "~6.0.60", "@types/yfiles": "0.0.2", "chai": "4.0.2", "jasmine-core": "2.6.4", "karma": "1.7.0", "karma-chai": "0.1.0", "karma-chrome-launcher": "2.2.0", "karma-cli": "1.0.1", "karma-jasmine": "1.1.0", "karma-webpack": "2.0.3", "ngrx-store-freeze": "^0.1.9", "node-sass": "^4.5.3", "sass-loader": "^6.0.6", "webpack": "^2.5.1" } }

when is it planned to get @ngx-config/fs-loader: 6.0.0 on npmjs.org?

When is it planned to get the @ngx-config/fs-loader: 6.0.0 on https://www.npmjs.com/package/@ngx-config/fs-loader ?

thank

depend on Angular 2.0.0

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

Current behavior
@nglibs/config depends on Angular 2.4.0

Expected/desired behavior
It should depend on Angular 2.0.0

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

add pipe

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[x] feature request

Current behavior

Expected/desired behavior

This module is great, but it would be very helpful if you introduced a pipe

Minimal reproduction of the problem with instructions

n/a

What is the motivation / use case for changing the behavior?

Accessing config strings from templates
Please tell us about your environment:

• Angular version: 4.0.1

• Browser: [all ]

• Language: [all ]

• Node (for AoT issues): node --version = 6.9

manually trigger configuration resolution/load in AppComponent.ngOnInit.

I'm submitting a ... (check one with "x")

[x] feature request

Current behavior
Configuration is loaded before AppComponent.ngOnInit.

Expected/desired behavior
I would like to trigger config load manually, inside AppComponent.ngOnInit.

Minimal reproduction of the problem with instructions

@NgModule({
	bootstrap: [AppComponent],
	declarations: [
		AppComponent
	],
	imports: [routing,
		ConfigModule.forRoot({ provide: ConfigLoader, useFactory: (configFactory), deps: [Http, AdalService] }),
	],
	providers: [
		{ provide: 'ORIGIN_URL', useValue: location.origin },
	]
})
export class AppModule { }

export function configFactory(http: Http, adalService: AdalService): ConfigLoader {
	const staticConfiguration = {
		apiUrls: {
			'app': environment.anticipateApiUrl + '/app'
		}
	};
	const configBuilder = new ConfigMergeLoader([new ConfigStaticLoader(staticConfiguration)]);
	return adalService.userInfo.isAuthenticated ? configBuilder.next((res: any) => new ConfigHttpLoader(http, res.apiUrls['app'] + '/configuration')) : configBuilder;
}

What is the motivation / use case for changing the behavior?
The request to get config from WebAPI using ConfigHttpLoader must be authenticated. Authentication is resolved in AppComponent.ngOnInit using adalService.handleWindowCallback()

Please tell us about your environment:
NPM 5.0.2, Windows 10, VS2017

• Angular version: 4.1.3

• Browser: all

• Language: all

• Node (for AoT issues): node --version = 8

Function calls are not supported in decorators but 'ConfigModule' was called.

I'm submitting a ... (check one with "x")

[x ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior

export function configLoaderFactory(http: HttpClient): ConfigLoader {
const endpoint =./assets/configuration/config.json;
return new ConfigHttpLoader(http, endpoint);
}

@NgModule({
imports: [
ConfigModule.forRoot({
provide: ConfigLoader,
useFactory: configLoaderFactory,
deps: [HttpClient]
})
],...
This code causes the following error, when I try to update angular version to 9.
Error: error TS100: Error during template compile of 'AppConfigModule'
Function calls are not supported in decorators but 'ConfigModule' was called.
Any idea?

Expected/desired behavior

I should not cause an error.
Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

• Angular version: 9.1.6

• ngx-config/core version: 9.0.0
• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: 12.16.1
• Platform: Mac

• Others:

Breaking changes in 8.2.0

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->

v8.1.0...v8.2.0

How come this package have breaking changes in minor version?
Why is the upgrade to angular 9 is done in v8.2.0?
this will break lot of projects that depend on this module.
Please provide a fix in 8.2.1 or something.

my project uses angular 8,
and has a dependency

"@ngx-config/core": "^8.0.1"

8.1.0 has

{
"peerDependencies": {
  "@angular/common": ">=8.0.0 <9.0.0",
  "@angular/core": ">=8.0.0 <9.0.0",
  "@angular/platform-browser-dynamic": ">=8.0.0 <9.0.0"
  }
}

8.2.0 has

{
  "peerDependencies": {
    "@angular/common": ">=9.0.0 <10.0.0",
    "@angular/core": ">=9.0.0 <10.0.0",
    "@angular/platform-browser-dynamic": ">=9.0.0 <10.0.0"
  }
}

P.S. I am happy that you are supporting angular 9, and i'm grateful, but please follow semver, otherwise you gonna break lot of projects.

ionic 2

Maybe you can help. Do you know how to load the config.json with Ionic 2?

ConfigModule should be importable in every module

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[X] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior

The module gives an error if you import ConfigModule twice.

Expected/desired behavior

Since ConfigModule exports a pipe (which must be declared in every module which uses it) it should be imported in other modules, too, without forRoot.
It should be fine removing the check in the constructor of the module. Then, whoever uses it must be sure to use forRoot only once with the main injector.

Environment

• Angular version: 7

make use of Google's JS and Material2 style guides

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior

Expected/desired behavior

• public members without prefix & private members with underscore _ prefix
• add JSDocs

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

• https://github.com/angular/material2/blob/master/CODING_STANDARDS.md
• https://google.github.io/styleguide/jsguide.html
• https://github.com/ng-seed/angular-tslint-rules/issues/8

Environment

• Angular version: X.Y.Z

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

use HttpClient (4.3.0+) instead of Http

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[X ] Feature request
[ ] Documentation issue or request

Current behavior
The project depends on @angular/http module which will be replaced by new @angular/common/http module.

Expected/desired behavior
Remove dependency to @angular/http and use @angular/common/http

Environment

• Angular version: 4.3.6

How can you pass a configuration setting to a configurable modules forRoot method during import

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[X] Documentation issue or request

Current behavior
Everything works great but cannot figure out how to pass a configuration setting into MyModules forRoot method.

Expected/desired behavior
It would be great to get a quick addition to the documentation for this scenario

Minimal reproduction of the problem with instructions
I have a custom Module that takes a couple properties when calling forRoot I would like to pass the properites from the config service how can I do this

@NgModule({
  declarations: [InstrumentationDirective],
  imports: [
    MyCoolServicesModule.forRoot({
        ssoGateway: 'https://env-specific.ssogateway.com' // <-- How can i use the configService here to get this value 
   }),
  ],
// ...

What is the motivation / use case for changing the behavior?
I want to pass environment specific settings maintained in an external json / service to a configurable module so that it can work correctly in each environment.

Environment

• Angular version: 9.1.2

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

make get method can retrieve value at any deep

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

Current behavior

Expected/desired behavior
use features from @unlight 's fork

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

use gutil instead of console in gulp tasks

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

Current behavior
During code review, console seems as an unexpected statement.

Expected/desired behavior
console should be replaced by gutil.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

request header value

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior
@skorunka

Can I provide a request header value while making a request to API endpoint to get the configuration?

Expected/desired behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Environment

• Angular version: X.Y.Z

• Browser:

• Chrome (desktop) version XX
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

• For Tooling issues:

• Node version: XX
• Platform:

• Others:

using `ReflectiveInjector` with `ConfigService`

Hi,
when I usesed ReflectiveInjector with ConfigService I got an error:
Uncaught Error: No provider for ConfigLoader! (ConfigService -> ConfigLoader)

let injector = ReflectiveInjector.resolveAndCreate([ConfigService]); this.config = injector.get(ConfigService);

add `yarn.lock` to npmignore

I'm submitting a ... (check one with "x")

[X] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[ ] feature request

Current behavior
The npm package contains yarn.lock file

Expected/desired behavior
yarn.lock file must be excluded from redistributable package.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

implement universal-loader w/caching

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

Current behavior
The universal-loader must be implemented - retrieving the data using the fs on the server platform, and then caching the result when it will be requested again on the client platform.

Related issue: fulls1z3/universal#5

Expected/desired behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

Unrichable endpoint

It is possible to add a check on the correctness of the json, currently if there is any error it returns a simple unrichable endpoint which could waste a lot of time figuring out the error

separate loaders from the package

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

Current behavior
Current loaders and their dependencies cause bundle size on production environment to be increased dramatically (ex: http, lodash).

Expected/desired behavior
Publish each loader (except ConfigStaticLoader) in separate packages.

• `ConfigHttpLoader
• ConfigFsLoader
• UniversalConfigLoader

And also, refactor ConfigMergedHttpLoader into

• ConfigParallelLoader
• ConfigSeriesLoader
  or,
• ConfigMergedLoader

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

Support for Angular 14

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[x] Feature request
[ ] Documentation issue or request

Current behavior
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: [email protected]
npm ERR! Found: @angular/[email protected]
npm ERR! node_modules/@angular/common
npm ERR! @angular/common@"^14.0.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @angular/common@">=9.0.0 <10.0.0" from @ngx-config/[email protected]
npm ERR! node_modules/@ngx-config/core
npm ERR! @ngx-config/core@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See C:\Users\Admin\AppData\Local\npm-cache\eresolve-report.txt for a full report.

Expected/desired behavior
Need to be install successfully

Minimal reproduction of the problem with instructions
In angular 14 Project, try npm i @ngx-config/core

What is the motivation / use case for changing the behavior?
To be able to use ngx-config with the most recent angular version

Environment

Angular version: 14.0.0
For Tooling issues:

Node version: v16.13.1
Platform: Windows 10
Others:

rename to `@ngx-config/core`

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[X] feature request

Current behavior

Expected/desired behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

example of how to use with `ngrx` v4 and `effects`?

I'm submitting a ... (check one with "x")

[ ] bug report => check the README and search github for a similar issue or PR before submitting
[X] support request => check the README and search github for a similar issue or PR before submitting
[] feature request

I'm currently using ngrx and have migrated to v4 which is inline with Angular4 versioning (they want to make this the standard way of developing angular4 apps with the ngrx platform). Previously I was able to get my configuration bootstrapped prior to the ngrx effects being loaded immediatley but now in the ngrx v4 the effects seem to be loaded instantly and I'm not sure how I can now bootstrap my configuration. Because my ngrx effects are being injected with the config service and now the values are undefined because they are instantiated because the config is bootstrapped. This is quite a major breaking change from the ngrx side, however nobody has responded and I'm kind of looking at this repo with your knowledge to see if maybe you might have some working examples with applications that will use the ngrx platform.

depend on `@types/lodash` v4.14.55

I'm submitting a ... (check one with "x")

[X] bug report => check the README and search github for a similar issue or PR before submitting
[ ] support request => check the README and search github for a similar issue or PR before submitting
[ ] feature request

Current behavior

Expected/desired behavior

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.X

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Language: [all | TypeScript X.X | ES6/7 | ES5]

• Node (for AoT issues): node --version =

merge-loader doesn't merge

I'm submitting a ... (check one with "x")

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x ] Bug report  <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Support request => <!-- Please check the repository for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request

Current behavior
Merge loader doesn't merge configs, the latter replaces the former.

Expected/desired behavior
Merge loader should merge.

Minimal reproduction of the problem with instructions

export function configFactorySeries(http: Http): ConfigLoader {
    const localConfigLoader = new ConfigStaticLoader({
        MyData: ['aa', 'bb']
        })

    const httpConfigLoader = new ConfigHttpLoader(http, './assets/config.json')

  return new ConfigMergeLoader([localConfigLoader])
    .next((res: any) => httpConfigLoader)
}

What is the motivation / use case for changing the behavior?

Environment

• Angular version: 4.3.3

• Browser:

• [x ] Chrome (desktop) version XX

• For Tooling issues:

• Node version: 6.11.3
• Platform: Linux

• Others:
  This happens when merging HttpConfig with LocalConfig.