TryKickoff / kickoff

:basketball: A lightweight front-end framework for creating scalable, responsive sites. Version 8 has just been released!
http://trykickoff.com
MIT License
463 stars 59 forks source link

Kickoff v9 #192

Open ashleynolan opened 7 years ago

ashleynolan commented 7 years ago

In progress

mrmartineau commented 7 years ago

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

jpdriver commented 7 years ago

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

mrmartineau commented 7 years ago

@jpdriver perhaps, what would be the replacement?

ashleynolan commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

jpdriver commented 7 years ago

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

ashleynolan commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

ashleynolan commented 7 years ago

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

rentorm commented 7 years ago

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?