Kickoff v9

[ashleynolan]

In progress

[ashleynolan]

More a question than a comment – what’s the reason we are using pixels over the font-size mixin in the styleguide?

[mrmartineau]

@ashleynolan as I mentioned in 4ba354f, all font-based values that are written in px will be converted to rems at build stage by the PostCSS-pxtorem function.

The reason is that all conversion functions written in Sass are extremely fragile, particularly when there's an unknown type used as the argument. The pxtorem process is extremely reliable and the new dev experience is much more easy to understand - just write in px and we'll do the rest. 🙂

[mrmartineau]

also, those values are specific and not sized using the modular scale.

[ashleynolan]

Ah ok – that makes sense if they don’t need to hit the modular scale functions ⚡️

[ashleynolan]

Looks good to me – only one small question on the styleguide.

[mrmartineau]

I'm pretty happy with these changes, shall we merge in today?

[jpdriver]

@mrmartineau any chance we could look at moving away from eyeglass as part of V9?

[mrmartineau]

@jpdriver perhaps, what would be the replacement?

[ashleynolan]

@mrmartineau Think we need to update the grid as well as otherwise this’ll break the breakpoints in there.

@jpdriver What’s the issue with using eyeglass?

[jpdriver]

@ashleynolan eyeglass appears to be solely geared towards building with node-sass.

if you want to compile Kickoff's SCSS with other tools (in my case Webpack) the @import statements referencing other NPM modules throw resolution errors.

thus far, i've been solving this by replacing the original source with a webpack-friendly copy of any files that use eyeglass imports:

  // Overwrite SCSS that uses Eyeglass (hack to avoid incompatibility issues)
  var indexPath = 'kickoff/scss/kickoff.scss';
  var indexSrc = ownPath + '/template/src/' + indexPath;
  var indexDest = appPath + '/src/' + indexPath;
  spawn.sync('cp', [indexSrc, indexDest], { stdio: 'inherit' });

  var resetPath = 'kickoff/scss/_reset.scss';
  var resetSrc = ownPath + '/template/src/' + resetPath;
  var resetDest = appPath + '/src/' + resetPath;
  spawn.sync('cp', [resetSrc, resetDest], { stdio: 'inherit' });

that works ok, and it is only two files -- kickoff.scss and _reset.scss, but if we can find an alternate that works across environments that'd be neat...

[ashleynolan]

@jpdriver We’re setting up a project using Webpack and Eyeglass and I don’t think we’ve had any issues so far with it. Have you raised it as an issue on the Eyeglass repo to try and get more info?

I haven’t tested out any decent alternatives, but the main thing I found that Eyeglass supported that other similar modules didn’t was resolving multiple packages pointing at the same dependency – namely not outputting the Sass for a module twice. Main use-case for this is if 2 modules happen to rely on another (for example, the grid) that it doesn’t create 2 lots of grid CSS.

[mrmartineau]

@ashleynolan I actually started an issue on this subject and there appears to be some solutions.

What this effectively means is that we will move to use Webpack for compilation of both CSS and JS, thereby removing eyeglass, node-sass etc. This would mean that both the react projects and standard Kickoff projects would use the same build - this was always my intention.

[jpdriver]

i mean personally i'd like that even better; but is this going to fall into the same fate as V8 where we decided there were already enough moving parts without migrating the tooling too?

[mrmartineau]

@jp if we can get it done, I would be massively happy.

[jpdriver]

ok how about we keep this as V9 without the tooling changes, but branch off this for V9 + only Webpack?

[ashleynolan]

@mrmartineau Probably best to open a separate issue to discuss this, as seems this is a bigger discussion.

Wouldn’t a better solution be to modularise the gulp tasks – that way we could create separate modules that can be used dependent on the setup that someone wants?

I personally wouldn’t want the CSS builds to move to using Webpack – I like having the option of using Webpack or not and so baking it into the entire build would mean that Kickoff would effectively become useless to me. Tbh if we were to do that, we may as well get rid of Gulp then too and move the entire project over to Webpack.

[mrmartineau]

@ashleynolan we could provide multiple build setups, but they all need to be maintained. Using Webpack to compile allows us to share build tooling with the react-based projects that we have. In my opinion, it shouldn't matter a given project uses to compile it's assets (one of the reasons we stuck with Grunt for so long), but we need to move with the times and allow an extensible setup that is more forgiving for the various project types that rely on the framework.

Regarding the removal of gulp: I don't think that we will remove it completely because gulp does some things that Webpack does not e.g. copy/delete tasks - which actually could be simple npm scripts, but I digress..

[mrmartineau]

btw @jpdriver lets get a working version of a Webpack only setup (where possible) and compare.

[ashleynolan]

@mrmartineau @jpdriver Have opened an issue so can discuss that out of this PR.

[rentorm]

I am also for full webpack support as I'm currently struggling to implement Kickoff in a project which is using only webpack and isomorphic-style-loader. @jpdriver have you used kickoff already in any project where only webpack is used for compiling JS and SCSS?