web-dev-qa-db-fra.com

Passage de Gulp à Webpack

Ma première question porte sur les recommandations de ce commutateur pour les projets simples, juste pour prétraiter/concaténer/minimiser?

Comprendre ces futures "normes", comme Webpack avec PostCss-NextCss-Autoprefixer, etc., c'est comme m'obséder ....

Cela mène donc à ma prochaine question. Existe-t-il un tutoriel qui vous guidera vers des tâches simples comme celle que j'ai décrite dans ma première question?

Ou est un moyen facile de changer mon gulpfile.js en un webpack-config.js

Mes tâches normales chez gulp ne sont pas les meilleures pratiques mais fonctionnent bien:

//load plugins
var gulp    = require('gulp'),
runSequence = require('run-sequence'),
sass        = require('gulp-Ruby-sass'),
compass     = require('gulp-compass'),
rev         = require('gulp-rev'),
revDel      = require('rev-del'),
del         = require('del'),
minifycss   = require('gulp-minify-css'),
uglify      = require('gulp-uglify'),
rename      = require('gulp-rename'),
concat      = require('gulp-concat'),
notify      = require('gulp-notify'),
plumber     = require('gulp-plumber'),
watch       = require('gulp-watch'),
path        = require('path');


  //the title and icon that will be used for the Grunt notifications
  var notifyInfo = {
    title: 'Gulp',
    icon: path.join(__dirname, 'gulp.png')
  };

  //error notification settings for plumber
  var plumberErrorHandler = { errorHandler: notify.onError({
    title: notifyInfo.title,
    icon: notifyInfo.icon,
    message: "Error: <%= error.message %>"
  })
};

//patches
var paths = {
  scriptsAbs : '_coffeescript/',
  stylesAbs: '_scss/',
  scriptsCom : '_coffeescript/' + '**/*.js',
  stylesCom :'_scss/' + '**/*.scss',
  cssCom : 'resources/css',
  jsCom : 'resources/js',
  imgCom : 'resources/img'
};

gulp.task('clean',
  function (cb) {
    del([
      paths.cssCom + '/*',
      paths.jsCom + '/*'
      ], cb);
  });

//styles
gulp.task('styles',
  function() {
    return gulp.src(paths.stylesCom)
    .pipe(plumber(plumberErrorHandler))
    .pipe(compass({
      sass: '_scss',
      css: paths.cssCom,
      image: paths.imgCom,
      style: 'expanded',
      relative: true,
      require: ['normalize-scss', 'susy']
    }))
    .pipe(gulp.dest(paths.cssCom))
    .pipe(rename({ suffix: '.min' }))
    .pipe(minifycss())
    .pipe(gulp.dest(paths.cssCom))
    .pipe(rev())
    .pipe(gulp.dest(paths.cssCom))
    .pipe(rev.manifest())
    .pipe(revDel({ dest: paths.cssCom }))
    .pipe(gulp.dest(paths.cssCom))
    .pipe(notify({ message: 'Styles task completed' }))
  });

//scripts
gulp.task('scripts',
  function() {
    return gulp.src(paths.scriptsCom)
    .pipe(plumber(plumberErrorHandler))
    .pipe(concat('main.js'))
    .pipe(gulp.dest(paths.jsCom))
    .pipe(rename({ suffix: '.min' }))
    .pipe(uglify())
    .pipe(gulp.dest(paths.jsCom))
    .pipe(rev())
    .pipe(gulp.dest(paths.jsCom))
    .pipe(rev.manifest())
    .pipe(revDel({ dest: paths.jsCom }))
    .pipe(gulp.dest(paths.jsCom))
    .pipe(notify({ message: 'Scripts Concatenated completed' }))
  // .pipe(reload({stream:true}));

});


gulp.task('default', ['clean','styles','scripts'], function(){
  gulp.watch(paths.stylesCom, ['styles'])
  gulp.watch(paths.scriptsCom, ['scripts'])

//watch .php files
// gulp.watch(['*.php'], ['bs-reload'])
});

Et je commence à utiliser postcss, ce qui facilite mon flux de travail, mm, mieux .. parfois plus facile.

Quelles sont vos opinions sur tout cela? Où est la bonne voie pour commencer?

EDIT // 28 JUIN 2017

A cette date, nos progrès avec Webpack 1 ont été très satisfaisants et ont abouti, notre flux de travail est bien plus rapide et notre dépendance à cet outil est Inchangeable.

Ceci est le webpack.config.js que nous utilisons tous les jours:

"use strict";

var webpack = require('webpack');
var glob = require('glob-all');
var ExtractTextPlugin = require("extract-text-webpack-plugin");
var BrowserSyncPlugin = require('browser-sync-webpack-plugin');

let start = {

    entry: {
        scripts: glob.sync(
            [
            './_javascript/*.js',
            './_cssnext/*.pcss'
            ]
        )},

    output: {
        path: './resources/js',
        filename: 'bundle--[name].js'
    },
    watchOptions: {
        poll: true
    },

    postcss: function (webpack) {
        return [
            require("postcss-import")({addDependencyTo: webpack}),
            require("postcss-url")(),
            require("precss")(),
            require("postcss-cssnext")(),
            require('postcss-font-magician')(),
            require("postcss-reporter")(),
            require("postcss-browser-reporter")(),
            require('postcss-inline-svg')(),
            require('postcss-urlrev')(),
            require('postcss-fontpath')(),
            require('postcss-object-fit-images')()
        ]
    },

    module: {
        loaders: [
            {
                test: /\.jsx?$/,
                loader: 'babel-loader'
            },
            {
                test: /\.p?css$/,
                loader: ExtractTextPlugin.extract(
                    'style-loader',
                    'css-loader!postcss-loader'
                )
            }
        ]
    },


    plugins: [
        new webpack.optimize.CommonsChunkPlugin({name: 'scripts', filename: 'bundle--[name].js'}),
        new webpack.optimize.UglifyJsPlugin({
            compress: {
                warnings: false
            }
        }),
        new ExtractTextPlugin("../css/bundle--styles.css"),
        new BrowserSyncPlugin({
            Host: 'localhost',
            port: 3000,
            proxy: 'localhost:8002',
            browser: 'google chrome',
            ghostMode: false
        })
    ]

};

module.exports = start;

Mais les temps ont changé et il est temps d'évoluer vers Webpack 3 et nous sommes maintenant en train de changer ce webpack.config.jsen version 3 

UPDATE 24.07.17 || v1 (Tryout 10000.1)

[ Passer de Webpack 1 à Webpack 2/3 ]

gulpwebpackpostcss
15
Locke

Pour des projets simples, je ne recommanderais pas du tout l’interrupteur. Au final, c’est un goût personnel, je pense, et je préfère le post-traitement par javascript (gulp) facilement compréhensible.

Comme vous l'avez dit dans votre question, votre configuration actuelle fonctionne bien: alors pourquoi réparer quelque chose qui n'est pas défectueux? Je me concentrerais sur la refactorisation de votre code gulp pour le rendre un peu plus lisible, divisez les fonctions longues en tâches plus petites.

En fin de compte, utiliser Webpack nécessite d’apprendre de nombreuses options de configuration spécifiques à Webpack, tandis qu’avec gulp, vous ne faites que pipeter des commandes Vanilla js.

5
Oli

Ok, je suis en train d’obtenir de très bons résultats grâce à cette tutroiale: https://www.phase2technology.com/blog/bundle-your-front-end-with-webpack/

Ma première approche est la suivante:

webpack-config.js

'use strict';

const webpack    = require('webpack'),
    path         = require('path'),
    autoprefixer = require('autoprefixer'),
    glob         = require('glob');

let script = {
    entry: {
         'scripts': glob.sync('./_javascript/*.js'),
    },
    module: {
        loaders: [
            // Javascript: js, jsx
            {
                test: /\.jsx?$/,
                loader: 'babel-loader'
            },
            // CSS: scss, css
            {
                test: /\.s?css$/,
                loaders: ['style', 'css', 'sass', 'postcss-loader']
            },
            // SVGs: svg, svg?something
            {
                test: /\.svg(\?.*$|$)/,
                loader: 'file-loader?name=/img/[name].[ext]'
            },
            // Images: png, gif, jpg, jpeg
            {
                test: /\.(png|gif|jpe?g)$/,
                loader: 'file?name=/img/[name].[ext]'
            },
            // HTML: htm, html
            {
                test: /\.html?$/,
                loader: "file?name=[name].[ext]"
            },
            // Font files: eot, ttf, woff, woff2
            {
                test: /\.(eot|ttf|woff2?)(\?.*$|$)/,
                loader: 'file?name=/fonts/[name].[ext]'
            }
        ]
    },
    output: {
        path: './resources/js',
        filename: 'bundle--[name].js'
    },
    plugins: [
        new webpack.optimize.CommonsChunkPlugin(['scripts'], 'bundle--[name].js'),
        new webpack.optimize.UglifyJsPlugin({
      compress: {
        warnings: false
    }
})
]
};

let style = {
    entry: {
        'styles': glob.sync('./_nextcss/*.css'),
    },
    module: {
        loaders: [
            {
                test: /\.s?css$/,
                loaders: ['style', 'css', 'sass', 'postcss-loader']
            },
        ]
    },
    postcss: function (webpack) {
        return [
            require("postcss-import")({
                addDependencyTo: webpack
            }),
            require("postcss-url")(),
            require("postcss-cssnext")(),
            require("postcss-browser-reporter")(),
            require("postcss-reporter")(),
        ]
    },
    output: {
        path: './resources/css',
        filename: 'bundle--[name].css'
    },
};

module.exports = [
    script,
    style,
];

Cela génère un bundle--script.js avec succès, mais j'ai quelques problèmes avec la partie css.

Cela ne pré-traitera rien: /

Je ferai la mise à jour ici si je dois travailler dans l'intervalle, j'apprécierai vraiment beaucoup si quelqu'un peut me guider.

5
Locke

Les concepts de Gulp et de Webpack sont assez différents: vous dites à Gulp comment d'assembler le code frontal pas à pas, mais vous indiquez à Webpack quoi que vous souhaitez via un fichier de configuration. . Il n’existe donc pas de mappage facile un à un si vous changez de poste.

Notre société est passée de Gulp à Webpack au cours de la dernière année. J'ai trouvé que la compréhension des différences entre les deux outils est très utile pour la transition. Voici un court article (5 min de lecture) que j'ai écrit pour expliquer le changement de mentalité: https://medium.com/@Maokai/compile-the-front-end-from-gulp-to-webpack-c45671ad87fe

Bien que notre transition ait pris un certain temps, nous avons compris comment transférer tout ce que nous avons fait à Gulp vers Webpack. Donc, pour nous, tout ce que nous avons fait à Gulp peut également être fait via Webpack, mais pas l’inverse.

1
Maokai

Cela dépend de la réponse à la question: voyez-vous un avantage à charger ou non des css dans le paquet Webpack? Si vous voulez charger css sur le navigateur avec <link>, alors webpack ne vous apportera probablement aucun avantage. 

Sauf d'avoir "un seul outil". Mais pas une configuration - n’oubliez pas que vous avez toujours besoin d’une configuration Webpack spécifique ne compilant que css pour le développement speadup (la compilation js est très lente) et qu’elle n’est pas aussi facile à réaliser css seulement). 

0
Roman Pokrovskij

Je ne pense pas que vous auriez besoin d'un chargeur postcss. Je veux dire, pour le moment. Vous ne faites que passer d'un outil à un autre, vous devez donc rester aussi mince que possible.

{ 
  test: /(\.css|\.scss)$/, 
  include: path.join(__dirname, 'src'), 
  loaders: ['style-loader', 'css-loader', 'sass-loader'] 
}

Remarquez que include dans mon code dépend de votre configuration. Après cela, je penserais à me débarrasser du chemin «relatif» que vous avez en gulp. Cela pourrait casser vos affaires si vous vouliez maintenir un environnement development et production. Juste une expérience personnelle.

0
Ematipico