-
Notifications
You must be signed in to change notification settings - Fork 12k
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
Comments
@JohannesHoppe Seems like the the discussen revolved around the issue with systemJS and barrels. I would like to see barrels back into the CLI. Makes importing things way better. |
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? 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 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. 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. |
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. |
The official stance right now is that barrels are not a style guide recommendation per se, as the introduction of 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. |
Good decision. Barrels are a smart thing for large scale applications, it should be something that developers get used to ;) |
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:
The index.ts contains this:
Inside the common-data-routing.module, I do this:
The above doesn't work. What works is only this:
No error is generated, it is just the screen is not displayed. Any idea? |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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!
The text was updated successfully, but these errors were encountered: