V4 -- Config error on installing w/ PostCSS support

[sthzg]

When installing with PostCSS support, the postcss config property seems to be inserted at the wrong place (the config fails webpack configuration).

Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration has an unknown property 'postcss'. These properties are valid:
   object { amd?, bail?, cache?, context?, dependencies?, devServer?, devtool?, entry, externals?, loader?, module?, name?, node?, output?, plugins?, profile?, recordsInputPath?, recordsOutputPath?, recordsPath?, resolve?, resolveLoader?, stats?, target?, watch?, watchOptions? }
   For typos: please correct them.
   For loader options: webpack 2 no longer allows custom properties in configuration.
     Loaders should be updated to allow passing options via loader options in module.rules.
     Until loaders are updated one can use the LoaderOptionsPlugin to pass these options to the loader:
     plugins: [
       new webpack.LoaderOptionsPlugin({
         // test: /\.xxx$/, // may apply this only for some modules
         options: {
           postcss: ...
         }
       })
     ]

/cc @stylesuxx

[stylesuxx]

Ahh, right - this property... I am on it.

[sthzg]

@stylesuxx let me know if I can be of any assistance with testing/fixing this bug.

[weblogixx]

@stylesuxx / @sthzg: Maybe we should add the default key and remove the question on installing if this is possible? Users would then only have to install the postcss node modules per hand and the config would not have to be altered as it is today. What do you think about this?

[sthzg]

@weblogixx just a short follow-up: @stylesuxx came up w/ a PR that fully integrates the PostCSS functionality again #313. The only thing left to merge this PR in is a final, manual check.

[weblogixx]

Hi @sthzg,

nice, will also have a look at it. I really dislike the way we are reparsing the config with esprima in the current version, just wanted to remove this if it is possible.

[stylesuxx]

Imho it would have no negative effect to add it by default. If the user chooses not to use it, nothing changes, if he wants to use it, he simply adds the plugins. We could then handle it via non ast parsing. Let me know how I should handle it, should not be too much of a hassle. Am 25.11.2016 17:26 schrieb "Chris" <notifications@github.com>:

…

Hi @sthzg <https://github.com/sthzg>, nice, will also have a look at it. I really dislike the way we are reparsing the config with esprima in the current version, just wanted to remove this if it is possible. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#307 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA7tELjR_V-gdKQwBLTL4HoISReUYi-Mks5rBwxSgaJpZM4K5UG_> .

[weblogixx]

@stylesuxx, yes, that would be the way to go for me. In this case, we just would have to remove the question (add postcss support) when using v4 and up, so v3 would still implement it.

[sthzg]

Cool, then I defer the manual testing until after these new changes.

[sthzg]

@stylesuxx I started to prepare the gen-side in above's commit (cece8d0).

The error on Travis is on purpose, as the updated tests require removing the postcss and postcss-loader deps on the template repo (I've commented on the PR there).

Maybe you could also look over this PR. I am not sure if we could get rid of some of the deps that were necessary for AST processing in the postcss.js install step (now removed, some of the AST deps are required by the setup-env subgen though).

IMO we can now finish testing with the combination of

• your PR version on the template repo and
• this PR's version of the generator

and then maybe finally ship this thing 🙌 ...