-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Clean dev dependencies #985
Comments
The leaner the better! I personally would be happy to kiss all those good bye. |
For reference: Original seed:
|
Availability of 2 variants would be fine. |
Supporting three versions of the seed (minimalistic, the current one and the advanced seed of @NathanWalker) seems like a lot of effort, that I'm not sure is worth it. The minimalistic seed could be turned into the current version by adding Sass and css linting, which if required, is matter of a couple of hours. |
I would like to use |
Hi! For example:
Those dependencies got included when @hank-ehly inlcuded the sass build option. People were happy to be able to use sass by a simply enabling a configuration flag. If we were to drop those, we would in consequence need to revert this build option too. Surely we cannot make everyone happy and there will always be some "I want to use A) Absolute bare minimum seed
Pro
Con
B) Provide a seed for the 80% use-cases
Pro
Con
That are my thoughts on that. Greetings Dope |
I would much prefer a minimalistic seed that only handles bundling and testing the script part. For everything else: Maybe a collection of receipts of "How do I add x?" would be nice and help everyone to setup projects to their needs? |
@sebald I'd appreciate your feedback for the minimalistic branch. |
@mgechev It certainly looks like a loot of stuff, but almost everything is needed. Exceptions are (imho):
The hard part, if think, is that it looks so damn much stuff. But in reality it isn't. You removed all the "unnecessary" stuff in 467e6f2#diff-b9cfc7f2cdf78a7f4b91a753d10865a2 already. I really like that you hide tasks than actually run gulp with npm scripts. It good to have only on "task runner". Maybe going all the way would be an option? Meaning, hiding that gulp is used at all and instead of having a task to list all gulp tasks use this https://github.com/srph/npm-scripts-info ? I also used https://www.npmjs.com/package/npm-run-all in the past, which is super helpful :) @TheDonDope already mentioned it. Updating the wiki more frequently. It may be hard to keep it updated with the pace this seed changes, but it is also super important, because let's be honest: we just wanna ...and because I do not wanna end my post with a negative statement: Dude, I have used this seed back in den Angular Beta so so many times to see how the API changed and play around with the upcoming Angular. Even if people do not use or appreciate this seed, b/c there is ng-cli, it is such a fantastic learning resource! Finally I know how to get coverage reports with TS! Thanks a lot for all the work and heart you put into this. |
Thanks for the feedback (it wasn't negative at all, it was quite constructive :-))! Currently we use We're not competing with |
I'm also on the side to keep it minimalistic. |
If the goal is to be minimalistic and only require what is basically necessary, sass is not necessary and could be removed; although, I am sad to see it removed only 2 weeks after creating it. I would like to request that the goal of the repository be made more apparent. The word minimalistic doesn't appear in the README. I think being more explicit about the goal of the repository will help future contributors understand what modifications are and aren't desirable. |
I'd suggest to apply the minimalistic approach and add/update the information for:
|
Why don't we finishing the current refactoring and get it stable before we start gutting other stuff out.
As to what is proposed to be removed, it's useful to any project with a stylesheet so it doesn't make a great deal of sense to me but w/e. As to why it's being removed, you can attribute a great deal of that time increase to both npm the service, npm the package, your internet and the system you are installing on. My Point being, finish the major work that has lots of projects holding features & fixes until it lands before ripping out packages people probably use daily and will have to add back for the sake of ~75 seconds saved occasionally. |
Yes, it'll be best to have #959 in master before stripping dependencies. |
The finest "recipe for adding functionality X" is a working, tested, maintained version with functionality X. So I don't see how forcing people to constantly update docs is easier or better for anyone than going ahead and just updating code. This is why comments/jsdoc have fallen away in usage and been replaced by test suites for teaching people how things work and why. Text goes stale too easily. It's also hard for me to imagine people wanting a truly "minimal" seed (wouldn't the CLI be that?). Why would someone invest the time in learning an mind-numbingly complex web framework like NG2 but not want advanced CSS processing like Sass/PostCSS? "Lightweight" is a buzzword, people actually want everything to "just work." Encouraging branches & forks rather than discouraging them seems the only reasonable option if this is too much maintenance or install time for you. Eventually maybe someone will make a configurator tool that lets you check off what components you want or don't in your starter. But the code must be present and running to enable that. Thanks so much for your brilliant work! |
So where to draw those lines? Some people like bootstrap and others material design, and so one... Imho there is no "right" way to handle these in the seed. |
I think the issue here (if I can read Minko's mind) is he doesn't want to feel responsible for breaking someone's branch or fork. So he wants only two to worry about, one minimal (his) and one "advanced" (Nathan's). Fine but the idea of open source is it lets you, in the words of one wag, "Move fast and break things." So everyone can decide what they want to worry about and let the crowd figure the other things out. I don't see his responsibility to add-on developers as particularly more burdensome than to end-users (the nature of this project discourages breaking anything arbitrarily). And I think developing an add-on to the seed would be a nifty little project for people, with its snacks of keeping up with updates. So let a thousand flowers bloom and git and npm will let us roll back to the last known stable version of whatever component we want that hasn't been maintained promptly. Everyone can decide how much effort and responsibility they want and pick up where someone else got bored and slagged off. I'm fine with stripping any running code out of master, I just hope it goes somewhere better than /dev/null. And it would be nice for the mother to encourage that. =) |
To @tarlepp 's point, the line is actually quite simple in my mind. This is a set of Looking at what is proposed to be removed, examine the function of the lib.
All that said, none of this makes any difference to me at this point and I have no real argument for or against other than the logical one above. |
@d3viant0ne the minimalistic branch contains the dependencies you've mentioned except the phantomjs-launcher. Running the tests in this headless browser requires a binary which needs to be downloaded both by us and CI. Also, currently we're running tests only in Chrome so phantomjs is not used. |
@d3viant0ne l did a small step which will not introduce breaking changes but on the other hand will speed-up the initial installation quite a bit! Since we're primary using Chrome, I suggest to drop the PhantomJS launcher and keep the Sass support for now #1027. |
After the discussion I believe that we concluded that dropping the Sass support will bring only more questions and confusion. So lets keep the seed like it is and close this issue :-). |
From our initial goal to keep the seed minimalistic, it's set of dependencies grew over the last a couple of months. This made the entire installation process much longer, bringing a couple of extra plugins which may or may not be used by many.
I'm opening this issue with suggestion to drop:
audoprefixer
colorguard
doiuse
gulp-clean-css
gulp-postcss
gulp-progeny
gulp-sass
gulp-sass-lint
karma-phantomjs-launcher
(we already run tests in chrome)postcss-reporter
-
stylelint
stylelint-config-standard
I'd love to hear more thoughts. Do you really use all/any of these plugins or you prefer to keep the installation process lighter and get rid of them (or some of them)?
Note that there's a version of the seed which includes more functionality and respectively more dependencies here.
// cc @ludohenin @d3viant0ne @TheDonDope @NathanWalker @Shyam-Chen
The text was updated successfully, but these errors were encountered: