Remove remaining barrels

[JohannesHoppe]

Correct me if I'm wrong, but according to the discussion in "StyleGuide 04-10 - Barrels" barrels are not recommended anymore.

Please remove:

• https://github.com/angular/angular-cli/blob/master/addon/ng2/blueprints/ng2/files/__path__/app/index.ts
• https://github.com/angular/angular-cli/blob/master/addon/ng2/blueprints/ng2/files/__path__/app/shared/index.ts

from the blueprints!

[SanderElias]

@JohannesHoppe Seems like the the discussen revolved around the issue with systemJS and barrels.
But as CLI is now completely on webpack, and webpack works great with barrels.
Also in the node community, working with barrels is becoming more and more common.

I would like to see barrels back into the CLI. Makes importing things way better.

[JohannesHoppe]

Right now the single usage of the last remaining barrels is inconsistent. That’s the first point.

The other point is the general future of the style guide. Will be barrels deprecated or not?
In my opinion they make things more complicated, when people start to add more code into the index.ts. One example is adding a bunch of components to an array, for later imports. Before angular-modules this was a doable approach, but now we don’t need both solutions (in my opinion).

I would also vote for not having barrels at all, since I don’t want to have Angular code that depends on the module loader and/or the cli. The CLI should be transparent enough, that I could switch to any other approach (e.g. SystemJS) at any time.

But my arguments are not important here. I can live with both. But I really wonder about "StyleGuide 04-10 - Barrels" and what this means for the CLI.

[JohannesHoppe]

FYI, after #2056 the guilty guys are now here:

https://github.com/angular/angular-cli/blob/master/packages/angular-cli/blueprints/ng2/files/__path__/app/index.ts
https://github.com/angular/angular-cli/blob/master/packages/angular-cli/blueprints/ng2/files/__path__/app/shared/index.ts

[SanderElias]

@JohannesHoppe You can use barrels pretty seamless with ngModule. I wrote a small article over just that. It reduces the amount of boilerplate lines, and simplifies importing things in your application.
Reducing boilerplate is making better readable code.

I have not seen a technical reason for rejecting barrels. Even after digging in a bit more. Also talked a bit about it with @robwormald, He also liked the idea of using barrels the way I showed. there are some things that need attending, but he agreed that this use-case was a very valid one.

So I still think support for barrels should be back in. Perhaps behind a flag, that optionally enables it.

[kylecordes]

The big problem of barrels is not just a stylistic thing, it is that they make it exceedingly easy to accidentally have circular dependencies among your type script modules (not angular modules). As of at least a few betas ago with webpack, this broke everything. Although in theory the type script and es2015 module systems should handle circular dependencies fine, support is stuff in-progress for webpack 2.

Circular dependency do work OK with System, which is why the barrels were mostly OK with the older CLI. Once webpack supports this properly, then it may be suitable to revisit the idea of reintroducing barrels here. The problem was a couple of webpack betas ago - maybe it's already fixed? I don't know, but someone who does know, should lead the charge on this.

[filipesilva]

The official stance right now is that barrels are not a style guide recommendation per se, as the introduction of NgModule makes them less necessary.

Reexporting is still a useful technique with ES6 Modules though, so it's common enough to have a couple of reexporting barrels in an application. Hence we still have these barrels.

As @kylecordes says, there are webpack issues with circular dependencies, see #1831 for one such case.

[ovitrif]

Good decision. Barrels are a smart thing for large scale applications, it should be something that developers get used to ;)

[bhaidar]

I am finding a problem with barrels when used in Angular-cli. If a component is imported from a barrel, it is not being picked up and shown on the screen. However, when I import the component from its .ts file, it works fine. This is getting me amazed, why would this happen?

In my case, I have this structure:

• common-data module
• agency module
  • agency-list.component.ts
• index.ts
• common-data.module.ts
• common-data-routing.module.ts

The index.ts contains this:

export * from './agency/agency-list.component';

Inside the common-data-routing.module, I do this:

import { AgencyListComponent } from '../common-data'

The above doesn't work. What works is only this:

import { AgencyListComponent } from './agency/agency-list.component'

No error is generated, it is just the screen is not displayed.

Any idea?

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}