Skip to content

Remove remaining barrels #1978

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
JohannesHoppe opened this issue Sep 5, 2016 · 9 comments
Closed

Remove remaining barrels #1978

JohannesHoppe opened this issue Sep 5, 2016 · 9 comments

Comments

@JohannesHoppe
Copy link
Contributor

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

Please remove:

from the blueprints!

@SanderElias
Copy link

@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
Copy link
Contributor Author

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.

@SanderElias
Copy link

@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
Copy link

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
Copy link
Contributor

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
Copy link

ovitrif commented Oct 7, 2016

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

@bhaidar
Copy link

bhaidar commented Sep 4, 2017

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
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 7, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants