-
Notifications
You must be signed in to change notification settings - Fork 9
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
Maintenance issue: Exporting modules from silverstripe-admin is rigid #1
Comments
Good observation. Though I'd argue it's always been a bit rigid. Before this change, it still required updating multiple modules to add a new exposed package. Now it involves a version bump and and multiple upgrades across modules. It's definitely gotten more rigid. I think as a general principle what you're suggesting is sound, but there are some technical limitations we'd have to navigate to get there:
In an ideal world, we would make the source of truth a serialised (easily maintained) list of all the exposed packages that admin would read to build its Possible solution:
Alternatively:
My preference would be the first option, as it's completely obscured from the developer, provided he or she is using the yarn scripts, and it just creates a more intuitive place to expose globals. |
This is the kind of thing I was thinking about for "importing" into the webpack-config module. |
You could go the other way, and make bundle.js pull in all exposed modules from exports.json. |
The key is that |
Oh, I see. |
This would be the idea open-sausages/silverstripe-admin@82ade8b |
Would be good to get input from @flamerohr here too, |
I think generating expose calls by generating a list adds more complexity than necessary and distracts from the core of the issue here, externals need to be declared to webpack so that they do not get compiled into the bundle. I admit I'm very much against dynamic require/imports, as well as generating an import bundle, so I would like to brainstorm this a bit further and see if there are less complex solutions. I would like to focus the discussion more to the external list than expose-loader, if that's alright? |
Sure. So just to be clear, dynamic imports are off the table, as they defeat
I think it's important to remember the end game, here, which is to make the entire frontend layer less opaque and more accessible to thirdparty developers. A simple, easy to understand API for exposing your modules to other bundles is a key feature, IMO. I think we're limiting the scope by assuming that Another thing to consider: Could a lot of these |
Me pulling back the focus was because it's not just I wasn't keen on the idea of an Utilising Injector could be a good idea, it would mean we'd need to at least solve exposing Injector which is simple enough. |
So what I was envisioning is that modules could make their
That would offer a bit more flexibility and impose less structure on your module. I think an actionable task we can take out of this discussion is to review our |
I agree with that action :) and the position on anti-patterns, thinking about it actively exposing our files as globals seem like the anti-pattern. I would suggest limiting the |
Right, good point of clarification, there. So this really becomes more about exposing vendors and using DI for internal packages. Either way, we would still need to at some point afford thirdparty devs a way of exposing vendor libraries they're using. It's not critical, though. It just means that if you know another module exposes a library you need, you can make your library that much smaller. But if you don't know that, nothing really happens. You just use the local one. OK, so there's a story card in here. Will draw something up for @chillu . |
Sounds good :) I would assume that the thirdparty would expose their libraries as per the expose-loader, and if the external list is large enough, they can say "please use |
Another thought could be having Injector as a NPM library where (mind dumping while I'm working on something else) |
I had already tracked this issue in silverstripe/silverstripe-framework#5601, but this one has more detail in it, so closing the existing one as a duplicate. |
Right now if you want to add a new module export from silverstripe-admin it requires a new tag of webpack-config, and publishing it to NPM. This increases the risk of circular dependency chain of merge and release cycles, where webpack-config doesn't export modules necessary to complete builds, or alternatively falsely reports external dependencies which aren't a part of silverstripe-admin yet.
A better solution is to have https://github.com/silverstripe/webpack-config/blob/master/js/externals.js dynamically locate and export exposed modules from silverstripe-admin directly, via a separate include file distributed with admin directly.
The text was updated successfully, but these errors were encountered: