issue(docs): Resolve issues with extending seed to sass

[joshwiens]

At some point along the line, the seed & the wiki became out of sync

Short version, the sass/scss steps work but the styles aren't applied.
I'll deal with getting it working / correcting the docs.

Question: Does it make sense to pick a few very common configurations and then maintain them.
ex - sass/scss : bootstrap : material2 ( "supported extensions" from here down )

People already maintain these as projects but there is no merge validation against them so we end up inadvertently breaking common extensions to the project.

It may be enough to add validating supported extensions to our merge process and note a breaking change then create an issue to investigate the fix / update docs in either the seed or extension project.

//cc @mgechev @ludohenin

[mgechev]

Question: Does it make sense to pick a few very common configurations and then maintain them.
ex - sass/scss : bootstrap : material2 ( "supported extensions" from here down )

Definitely makes sense! We can list them here, as well as in the docs.

[joshwiens]

@mgechev - Do you happen to remember what version of the seed those docs were based off of?

I'd like to roll my own fork back to that version, and then use the update process to write out a proposal for the validation / notification workflow.

[mgechev]

We can compare with the wiki's revision history, not sure if all the revisions were actually valid.

[joshwiens]

Fair enough. I'll start from scratch and just build it myself.

[joshwiens]

@mgechev @ludohenin - This is going to require a change to either the testing scripts or the dev / prod build.

Without modifying the seed you can either get the tests working or you can get the sass working.

Question is, which route do you guys prefer we go?

[mgechev]

What are the changes that need to be performed? Change of the testing output directory?

[ludohenin]

Get the sass working and modify the test I suppose but don't really see the implications from there.

[joshwiens]

The crux of the problem right now is related to the components.

• If you target .scss in the styleUrl the tests will work as expected.
• If you target .css in the styleUrl the application will display the styles as expected.

It's not a major change either way but before I make a change to the seed portion that will have side effects for others, i'm curious which way we want to go with it.

[joshwiens]

@ludohenin @mgechev - So I had a thought.

I've used sass/scss for quite a while & I love some of the functionality. Variables, mixins, partials, imports and so on.

Issues

• Using a preprocessor is as much a pain in the ass as it is beneficial.
• Preprocessors are all or nothing, you get all the features or none of them.
• Preprocessors require additional tooling and time to the build process to eventually end up with css
• They are really an anti-pattern. You target one thing in your template but in reality it's targeting the compiled css.
• The Angular2 build pipeline is already heavy enough with TypeScript, adding another resource intensive integration. This really isn't doing people any favors, nor is it very forward thinking.

We already use postcss in the seed as part of our build process ( autoprefixer / cssnano ). Extending the existing postcss implementation to allow people to pick and chose the "sass-like" features they want without getting the baggage that comes with it should be far easier to support and more beneficial to the community as a whole.

Opinions?

[ludohenin]

Not sure, I don't do much css. But if I understand correctly, it's either sass or postcss but not both. If such is the case I'm fine if we ship with postcss by default. In the other and it would be nice to be able to swap that part of the build pipeline "easily".
What's the most painfull part with sass, so I have somewhere to start? :)
Is the inling plugin an issue in the process? we could think of "redesigning" it if needed.

[ludohenin]

It might also be good to wait for offline template compiler (not sure it's there in beta.15), it's going to change the general picture.

[joshwiens]

@ludohenin

But if I understand correctly, it's either sass or postcss but not both

Postcss and sass can live in the same place. Any implementation of sass ontop of the seed is using both now.

In the other and it would be nice to be able to swap that part of the build pipeline "easily"

This is being built using the project convention, I wasn't intending and trying to merge this into the seed itself. That said, the seed master is already using postcss which in essence is just an API to add plugins for stylesheet related functionality.

Autoprefixer & cssnano are both postcss.

function processComponentCss() {
  return gulp.src([
      join(APP_SRC, '**', '*.css'),
      '!' + join(APP_SRC, 'assets', '**', '*.css')
    ])
    .pipe(isProd ? plugins.cached('process-component-css') : plugins.util.noop())
    .pipe(plugins.postcss(processors)) // <--- executing postcss processing //
    .pipe(gulp.dest(isProd ? TMP_DIR: APP_DEST));
}

Is the inling plugin an issue in the process? we could think of "redesigning" it if needed.

Using a function in the styleUrl: is necessary to make the entire thing work. ( styles applied to app & the tests to function correctly ).

So after all the additions required in the wiki page for scss and then adding the styleUrl function to process the scss in the components, you end up taking a ~ 3 second performance hit.

I guess what i'm saying is though I initially though it would be a good idea to validate merges against a sass enabled fork of the seed, all of the effort is really producing negative value for the maintainers as well as the people who would use it.

I would think it a better solution overall to provide people with the functionality they need with a simplified implementation and faster execution.

[joshwiens]

Here is my biggest gripe with the whole preprocessor thing, the performance.

Using the same stylesheet layout with imports, mixins and so on to achieve the same functionality

scss watch cycle

postcss with imports & cssnext watch cycle

You can get the same functionality out of postcss as you can in sass in far less time and the implementation takes zero change to templates / tests to work.

Addition of one project task & two manual typings and you are off to the races.