refactor/export: export important functionality from main module #40
Conversation
|
Just thought I'd mention that personally I'm not a fan of the glob imports, mainly for reasons you've probably already heard before 😸 Although it saves a step for the writer, it puts an extra step in the process of determining where names are being imported from, which imported names are actually being used and what traits might different methods be coming from. Normally I like to opt for moving as much of the burden from the reader to the writer as possible, but everyone has their own opinion here so feel free to disregard this comment! |
|
@mitchmindtree : I mean in the end you don't have to use It's also just a first step, I just put in what I knew from experience you would usually need to use Collenchyma, but there might be a one or two that aren't really needed. So on one side we might clean that up a bit more once we start approaching a 1.0 state, on the other hand I would also like to add another module, which exports everything that is important for plugin developers (this was focused on plugin-users). |
|
@homu r+ |
|
📌 Commit 4aea78d has been approved by |
|
⚡ Test exempted - status |
refactor/export: export important functionality from main module
|
@mitchmindtree: Sorry if that sounded a bit too dismissive, but I think Collenchyma has some deficiencies on the user side, and this was definitely one of them. I've recently opened up a few issues to try and address that, but if anything comes to your mind, we would love your feedback :) |
|
This was changed a bit in #42. I forgot that a glob import of the root module would also import all the modules in it, some of which have names prone to colission (e.g. framework, plugin), especially with our plugins. This is now handled via a "prelude" module. |
refactor/export: handle import via prelude module [SKIP_CHANGELOG] REFERENCES #40
No description provided.