Remarks op huidig WIP

[thibmaek]

Webpack

Webpack 2 config ziet er uit wat ik gewoonlijk gebruik, enkele zaken die ik persoonlijk makkelijker werken vind:

• 1 base webpack.config.js die geimport wordt vanuit de webpack.config.production.js & webpack.config.development.js. Heeft naast het voordel van je configs overzichtelijker en more easily adaptable te maken aan een NODE_ENV ook nog het voordeel dat je voor een development NODE_ENV een andere, snellere devtool kan gebruiken zoals bv cheap-eval-source-map. Zie als ref bv de chart gelinkt in de comments op PR #12

Yarn

In referentie naar #11 (https://github.com/devinehowest/generator-devine-project/issues/11#issuecomment-257253934) heb ik niet direct een ander idee dan in de shell te checken met node's (child_process).exec en eventueel een env te exporten die je dependencytool instelt zodat je doorheen de scaffolding van jekyll in index.js de persoonlijke voorkeur van de user kan gebruiken. Is geen clean oplossing maar enige dat ik zo direct op kon komen. Iets in de trant van (untested code):

const exec = require(child_process).exec;
const output = (err, stdout, stderr) => console.log(stdout);
exec('if which yarn > /dev/null; then BUILDPACK=yarn; fi;', output);

Perf & etc

• package nodeVersion is lightweight maar kan waarschijnlijk zelf als dependency uitgesloten worden door node's native process.version. Die returnt wel een version string geprefixt met 'v' maar volgens mij kan het engines object in de package.json ook werken met prefixed versions ipv strict semver nummers
• Absolute paden ipv relatieve paden hebben voor mij altijd de voorkeur. Op kleinschalige projecten speelt het waarschijnlijk minder een rol maar op grotere projecten maakt het dat iets makkelijker om files van plaats te veranderen en je imports aan te passen.

[geoffreydhuyvetters]

2 aparte files snap ik inderdaad, hebben we ook even overwogen, maar is snel wel veel dubbele code. maar valt over te discussiëren, hebben het nu zo aangeleerd gekregen

source-map in dev is met een reden, breakpoints werkte niet in Chrome (was het toch hé @wouterverweirder)

yarn/npm check probeer ik zelf even uit, was aan het nadenken over een gelijkaardige aanpak

process.version kende ik niet, zal het aanpassen, lijkt me inderdaad logischer.

wat bedoel je met die absolute paden? altijd linken in je imports vanaf de root folder via webpack resolve? Ben daar zelf niet zo grote fan van, maar snap het gemak wel.

[thibmaek]

Lijkt me toch niet echt dubbele code of vat ik het verkeerd op? De config wordt in de huidige sowieso geexport als object dus in je webpack.config.production.js kan je iets doen in de aard van:

const base = require('./webpack.config.base.js');
const config = Object.create(base);

// -> config extenden voor production bv:
config.devtool = 'cheap-source-map';
…

en dan in de production run task de flag --config webpack.config.production.js doorpassen. Maar ofc snap ik dat dat weer extra aanleren is aan studenten 😄

Jep linken vanaf webpack root ipv import {…} from '../../Pages/Home.jsx'. Is een personal take ofc en hoeft (denk ik) niet gewijzigd te worden in resolve() in de webpack config.

PS: Wat is de beste manier om de generator lokaal te testen als je op je eigen branch werkt? Heb gekeken naar yarn link maar wordt niet herkend in yeoman in de shell.

[geoffreydhuyvetters]

ahja met 3 files, had het niet goed genoeg gelezen, ja kan, maar zal eerder iets voor volgend jaar zijn dan :)

dacht dat je voor die root paden resolve moet aanpassen.. moet het eens bekijken.

bij mij werkt lokaal testen via npm link perfect

ter info: https://github.com/devinehowest/generator-devine-project/commit/3918ce22490c718589e193ec5bc2a6a096465d11