automatically switch syntax by file extensions

[gucong3000]

• Add support for automatically switch the required syntax by file extensions
• Add support for handling different syntax files in one command

[coveralls]

Coverage increased (+0.3%) to 75.342% when pulling 3a67652 on gucong3000:postcss-syntax into 74119f4 on postcss:master.

[coveralls]

Coverage increased (+0.4%) to 74.825% when pulling 88ff080 on gucong3000:postcss-syntax into 3ec9b6e on postcss:master.

[RyanZim]

I'm not sure that I like the idea of this. You always have to install the correct parser/syntax for the file you're dealing with, so I don't see the point of not requiring config to use them. That just makes the dependency implicit vs. explicit.

[gucong3000]

I want try to if it's possible to use this project instead of stylelint's CLI.

postcss src/**/* -u stylelint

Most parser/syntax are installed in stylelint.

[gucong3000]

You always have to install the correct parser/syntax

How about install built-in some of the most commonly used parser/syntax?
convention over configuration

[RyanZim]

1. I don't want to bloat dependencies
2. PostCSS isn't really something that has convention over configuration. By default, it does absolutely nothing.
3. I'd guess probably 80% of PostCSS users just use the default syntax and don't care about other syntaxes.

[gucong3000]

https://www.npmjs.com/package/postcss-syntax?activeTab=dependencies

https://www.npmjs.com/package/postcss-less?activeTab=dependencies

https://www.npmjs.com/package/postcss-scss?activeTab=dependencies

I don't want to bloat dependencies

I've chosen three smallest packages for you.

[gucong3000]

PostCSS isn't really something that has convention over configuration.

@ai I think we should do something for this.
I think PostCSS should be as popular as babel, So maybe we should learn something like babel-preset-env.

[ai]

I agree with @gucong3000. I can’t find a popular case when you don’t need a postcss-scss to work with .scss. Also it prevent many mistakes.

“There is no dumb users, there is only bad UX” :D

PostCSS isn't really something that has convention over configuration

Nope. it is PostCSS Core, which is JS API. Look for Autoprefixer. It has a lot of “convention over configuration”.

By default, it does absolutely nothing.

I think the biggest our mistake in PostCSS was not to create some PostCSS Pack with best practice and plugins set. Most of the users will have some out-of-box solution. The other will use Core with own plugins.

Unfortunately, users are really bad with selecting plugins. Most just don’t know about other solutions.

[gucong3000]

There is some information for postcss syntaxes.

packages	dependencies	languages
postcss-scss	postcss	SCSS
postcss-sass	gonzales-pe, postcss	SASS
postcss-less	postcss@5.x.x	LESS
postcss-html	htmlparser2	html, html-like
postcss-markdown	remark, remarkunist-util-find-all-after	markdown
postcss-styled	null	template literals in js/ts
postcss-jsx	@babel/generator, @babel/parser, @babel/traverse, @babel/types	object/template literals in js/ts