feat(serve): Add -main flag for entry point

[jschwarty]

Feature requested

Would like to be able to change the main entry point script to use via a flag when running ng serve (as well as ng build).

ng serve -main main2.ts -e=someOtherEnvironment

Reason

While leveraging environment constants are handy to conditionally run code in your main.ts script, they don't get used by webpack (or AOT). So if you have some environment code that you don't want to include in your production build and you do the following in your main.ts:

. . .
if (environment.someOtherEnvironment) {
  myBootstrap(); // This function has imports that bring in other non-production code
} else {
  platformBrowserDynamic().bootstrapModule(AppModule);
}

Webpack will follow that function and its imports and will add that code to the bundles even when you ng serve or ng build.

Having the ability to target different main scripts would allow for ng serve and ng build to be used to build the appropriate code.

Then we could create different main files:
main.ts

. . .
platformBrowserDynamic().bootstrapModule(AppModule);

main.other.ts

. . .
myBootstrap();

And achieve optimal bundling of our app code based on our intended environment.

Notes

I'd be more than happy to add this feature, just want to confirm that it is something that people would feel would be worthy.

@hansl @robwormald

[FabioAntunes]

I just came across this question on stackverflow, that seems to be a perfect example why this might be useful

[ddehghan]

Hi Everyone - I wrote the SO question. The scenario is pretty simple. We dont want to ship all our test code for the mock services in the production build. It should be a pretty common use case.

[filipesilva]

Would you not be able to do your conditional imports from inside the environment files instead? And then expose whatever you need to main.ts (or any other file).

// environment.ts
import { MockX } from '../mocks/mock-x.ts';

export const environment = {
  production: false,
  extraProviders: [ MockX ]
};

// environment.prod.ts
import { RealX } from '../real/real-x.ts';

export const environment = {
  production: false,
  extraProviders: [ RealX ]
};

// app.module.ts
import { environment } from '../environments/environment';
//...
  imports: [
    BrowserModule,
    FormsModule,
    HttpModule,
    ...environment.extraProviders
  ],
//...

You're essentially asking for a split point where a file would be used to conditionally include static ES imports (and other code). In the scenario presented, the split point would be main.ts instead of environment.ts.

Unless I'm missing something, the only important thing is that somewhere this split point exists.

[filipesilva]

That being said, the environments functionality really does not discriminate. It's an absolute replacement. This works:

      "environments": {
        "source": "main.ts",
        "dev": "main.ts",
        "prod": "main.2.ts"
      }

I wouldn't recommend it overall because if some big change in the functionality is required this usecase won't be kept in mind. But currently, as far as webpack is concerned it's just a file replacement.

    extraPlugins.push(new webpack.NormalModuleReplacementPlugin(
      // This plugin is responsible for swapping the environment files.
      // Since it takes a RegExp as first parameter, we need to escape the path.
      // See https://webpack.github.io/docs/list-of-plugins.html#normalmodulereplacementplugin
      new RegExp(path.resolve(appRoot, appConfig.environments['source'])
        .replace(/[\-\[\]\/\{\}\(\)\*\+\?\.\\\^\$\|]/g, '\\$&')),
      path.resolve(appRoot, appConfig.environments[environment])
    ));

[jschwarty]

We still really need a way to run a different main.ts entry script. While the following does let us pull that off:

      "environments": {
        "source": "main.ts",
        "dev": "main.ts",
        "prod": "main.2.ts"
      }

...it complicates the ability to keep leveraging the environment constant in our applications.

Another option here (instead of or in addition to the ng serve flag for -main) could be to have the "main" property in the angular-cli.json config change to "mains" and work just like "environments":

      "mains": {
        "source": "main.ts",
        "dev": "main.ts",
        "prod": "main.prod.ts"
      }

[SamVerschueren]

Another option here (instead of or in addition to the ng serve flag for -main) could be to have the "main" property in the angular-cli.json config change to "mains" and work just like "environments"

That is exactly what I had in mind. It would be awesome to have something like that! But why use mains ? Can't we expand main to be a string (like it is now) and allow it to be an environmental object? Or use entrypoint as name could do as well. Just throwing out some ideas.

[filipesilva]

I'm still having some difficulty seeing why it's better to switch main.ts instead of environment.ts. To me it seems that one shouldn't be swapping the entry point because you still want the same app, you just want to have a different environment.

It's true that it's perfectly doable to add in main swapping but if there's a better abstraction (and I think the env files are one) then it's better to use that. Swapping main might be common for webpack users but not so much for other build stacks. If you're using the quickstart, for instance, using a different main involves changing code in a couple of places.

I know there have been a couple of theoretical examples in this issue already, but could you also give me a complete one (all the different file contents from a newly generated project) that illustrates the difference between swapping main.ts or environment.ts? That way I could run it and see if the env files really are insufficient.

[SamVerschueren]

I for instance swap my main file because in development I want the ngrx devtools but I don't want them in my production application. I'm on mobile now but will show my code examples when on the computer.

[SamVerschueren]

I'm on my computer so I can share some code.

Development

main.dev.ts

import './polyfills';

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { environment } from './environments/environment';
import { DevModule } from './app/dev.module';

platformBrowserDynamic().bootstrapModule(DevModule);

dev.module.ts

import { NgModule, Component } from '@angular/core';
import { StoreModule } from '@ngrx/store';
import { StoreLogMonitorModule, useLogMonitor } from '@ngrx/store-log-monitor';
import { StoreDevtoolsModule } from '@ngrx/store-devtools';
import { StoreUndoModule } from 'ngrx-undo';

import { AppModule } from './app/app.module';
import { rootReducer } from './shared/index';

@Component({
	selector: 'application-wrapper',
	template: `
		<sd-app></sd-app>
		<ngrx-store-log-monitor toggleCommand="ctrl-t" positionCommand="ctrl-m"></ngrx-store-log-monitor>
	`
})
export class ApplicationWrapperComponent { }

@NgModule({
	imports: [
		StoreModule.provideStore(rootReducer),
		StoreDevtoolsModule.instrumentStore({
			monitor: useLogMonitor({
				visible: false,
				position: 'right'
			})
		}),
		StoreUndoModule.interceptStore({
			bufferSize: 20
		}),
		StoreLogMonitorModule,
		AppModule
	],
	declarations: [ApplicationWrapperComponent],
	bootstrap: [ApplicationWrapperComponent]
})
export class DevModule {}

Production

main.prod.ts

import './polyfills';

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { enableProdMode } from '@angular/core';

import { environment } from './environments/environment';
import { ProdModule } from './app/prod.module';

enableProdMode();

platformBrowserDynamic().bootstrapModule(ProdModule);

prod.module.ts

import { NgModule, Component } from '@angular/core';
import { StoreModule } from '@ngrx/store';
import { StoreUndoModule } from 'ngrx-undo';

import { AppModule } from './app/app.module';
import { rootReducer } from './shared/index';

@Component({
	selector: 'application-wrapper',
	template: ` <sd-app></sd-app>`
})
export class ApplicationWrapperComponent {}

@NgModule({
	imports: [
		StoreModule.provideStore(rootReducer),
		StoreUndoModule.interceptStore({
			bufferSize: 20
		}),
		AppModule
	],
	declarations: [ApplicationWrapperComponent],
	bootstrap: [ApplicationWrapperComponent]
})
export class MainModule {}

---

As you can see, the production module does not bootstrap and show the ngrx devtools, but the development module does. If you have any feedback on to how it can be achieved without different main files, I would be happy to hear that. But for now, this is my use case why I need something like this setting or flag.

[filipesilva]

@SamVerschueren would this not work?

Essentially exporting Dev/Prodmodule as AppModule from within the environment file, and loading it in main.ts.

// main.ts
import './polyfills.ts';

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';
import { enableProdMode } from '@angular/core';
import { environment, AppModule } from './environments/environment';

if (environment.production) {
  enableProdMode();
}

platformBrowserDynamic().bootstrapModule(AppModule);

// environments/environment.ts
export { DevModule as AppModule } from '../app/dev.module';

export const environment = {
  production: false
};

// environments/environment.prod.ts
export { ProdModule as AppModule } from '../app/prod.module';

export const environment = {
  production: false
};

[jschwarty]

@filipesilva I like this solution. Works well to solve the "module to bootstrap" puzzle and the ability to do the rest of the conditional stuff in the environment files.

[SamVerschueren]

Cool, never thought about it like that. That would definitely work. Thanks!