You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 25, 2019. It is now read-only.
So Sagui is very useful for kickstarting projects but it starts becoming a hindrance in the long run, since one needs to understand how Sagui works behind the scenes and also understand all the deps (Karma, Webpack...) and sometimes it falls short. For bigger projects it is generally preferable to be close as possible to the "lower level" config. Having this in mind, two suggestions:
Export from Sagui
An export task that exports all sagui config. Once someone gets to the point sagui becomes impractical they run sagui export and continue from there.
Sagui as a config compiler
Here instead of seeing Sagui as a runtime generator of config, we see Sagui as a config compiler. Of course, it could have both moder. This means one runs sagui generate or sagui compile or something like that before running regular commands. These commands, in turn, will use already generated config, becoming much faster. User changes could be done in a different file and merged by sagui, solving the problem of conflicts when one regenerates the config. Ex:
This sounds fairly similar to create-react-app’s eject. To some extent, Sagui is built around the idea of not having to do that. Of course one has to be pragmatic so this can be a desirable feature.
I guess the central question is what specifically can’t be done without "exporting". Is this about having better transparency of the bundled configurations? I can imagine if we have userDefined files alongside the sagui ones means that users would be warned not to modify the sagui ones. Is that so?
In my POV question is not [only] what can't be done, but how difficult things start to become, since some functionality requires changes to sagui to be done. This is the main blocker.
So the idea is to modify the webpack.sagui.js, not just have it available to inspect? That’s what I don’t currently understand, I’m assuming that if the idea would be to modify it then just exporting to webpack.config.js and karma.config.js should do.
There is some background to this, which is why I mention create-react-app, one of the ideas behind Sagui is to try really hard to not having to export/eject. Exporting/ejecting means the end of updates to your project config. Sagui exposes escape hatches in the sagui.config.js so that corner cases can be covered, so I’m trying to understand what is the exact need behind exporting, maybe there is some change we can do so that is not necessary.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
So Sagui is very useful for kickstarting projects but it starts becoming a hindrance in the long run, since one needs to understand how Sagui works behind the scenes and also understand all the deps (Karma, Webpack...) and sometimes it falls short. For bigger projects it is generally preferable to be close as possible to the "lower level" config. Having this in mind, two suggestions:
Export from Sagui
An
export
task that exports all sagui config. Once someone gets to the point sagui becomes impractical they runsagui export
and continue from there.Sagui as a config compiler
Here instead of seeing Sagui as a runtime generator of config, we see Sagui as a config compiler. Of course, it could have both moder. This means one runs
sagui generate
orsagui compile
or something like that before running regular commands. These commands, in turn, will use already generated config, becoming much faster. User changes could be done in a different file and merged by sagui, solving the problem of conflicts when one regenerates the config. Ex:Of course names and paths are just what came to my mind, not a real suggestion.
The text was updated successfully, but these errors were encountered: