Gulp: development flag

[kettanaito]

This is more a usability issue regarding the development workflow.

Since we use gulp --dev in the most cases, and gulp quite rarely, it makes sense to make development a default environment (vice versa compared to what is it right now). So:

gulp // runs development mode

And

gulp --prod / gulp -p // runs production mode

I find this quite useful, but I want to hear your opinion as well.

[ronaldruzicka]

Good idea, I already used it like that on one of my own projects

[janpanschab]

There are 3 modes, the last one is not documented :-(

1. gulp --dev - runs dev mode
2. gulp build - runs production mode - only compilations
3. gulp - runs production mode with static server but without watch (gulp build + browserSync server)

Do we need 3rd mode? If yes, how would we run it?

[vbulant]

I like the third mode. Using it, you can test the proper bundling of all production assets.

[ronaldruzicka]

What about this?

1. gulp - runs dev mode
2. gulp build --prod - runs production build
3. gulp --prod - runs production build with browserSync

[kettanaito]

Well, I would suggest just flip the logic of gulp --dev right now, since refactoring all the tasks may take additional time and discussion (for example, prepare task is essentially build task, which runs differently in dev and prod, so it makes sense to have build and build --prod instead of prepare)

[vbulant]

Well, in the grand scheme of things, I think having PRODUCTION as default is always a good option.

[janpanschab]

Please think about all running projects. Imagine situation you are working on more than one project and you don’t know if run gulp or gulp --dev. How can we prevent this situation? The same for BE developers. They will hate us! Should we switch this commands on all projects? Or create some patch? Who will do it? What will be the timing?

[kettanaito]

@vbulant @janpanschab I understand the maintenance issues. But this would be a nice thing to have on new projects. If think about it, relying on implemented solution limits us in improving our devstack, we may have the same situation when migrating to Webpack, for example. This concerns almost any relatively big change.

But I really understand the consequences, I am just thinking of things which may make development process better. In the end, it is all about the agreement (somebody taught BE developers to run gulp --dev ;) )

[vbulant]

@kettanaito I’m not against improvements at all.

Let me explain my point of view.

The devstack is intended to be used throughout our local dev env and CI servers – Circle, .NET deployment, etc (correct me if I’m wrong, @janpanschab). And because CI servers are considered production envs, our devstack should default to production in my opinion.

It’s nice and convenient to have development env as default in case you use a devstack just for your development env or if you have separate pipelines for dev and prod…

So, back to your development as default point:

Maybe it can be done differently, eg. having gulp as development watcher and gulp build as production pipeline. But then we’d need to rethink our yargs based logic (--dev)…

Or utilize npm scripts and have "start": "gulp --dev" and "build": "gulp build" which is similar to create-react-app. But still, in case we do this, we need to ensure it’s used only for new projects so that it doesn’t break current/old ones (deployments).

But still, I’m perfectly OK with the current solution (default prod, optional dev) and I don’t think changing it is worth the effort. But I’m open to continue the discussion for sure.

[janpanschab]

I feel the same. I can sign it. @vbulant great explanation.

[kettanaito]

@vbulant then for the sake of better maintenance I would think of having 1 legacy version, and 1 up-to-notch version of development stack. Projects on older versions may utilize the devstack as they have used to, at the same time we will not have any obstacles to introduce really any technology we wish to new projects, without thinking of how it may affect the old ones.

This is more relative to the features to come, rather than to switching the default environment (just to be clear).

What a deep discussion that started :)

[vbulant]

@kettanaito When that time comes (need for split to legacy/top-notch versions), we can think about it for sure.

But I think generally it’s not a problem. When you add webpack instead of browserify, but the API stays the same (gulp build), it’s going to work just fine… So imho it’s not about features that much as it is about the API which is used by deployments, CLI etc…

[kettanaito]

@vbulant agree :)

Well, I don't think bringing another level of commands abstraction (in the form of npm scripts) is a good idea, it may lead to more confusion than easing in the workflow.