NPM Push for new error style about postcss-bem-linter

[davidtheclark]

I'd be in favor of a new release after the current issues are resolved. I wonder if it would be a good time to bump major release: since with the recent changes there's an API, having a major release number would be we could more meaningfully indicate with semver when that API has changed.

[necolas]

Before 1.0.0, the expectation is that minor version increases may break the API. I'd think I'd rather we stay at 0.x and iron out any kinks and instability before we're happy for 1.0.0. For example, going to 0.2 gives time for Twitter to use it for a few weeks and for any non-suit projects to try out the linter.

[davidtheclark]

Ok, sounds good.

[Kingdutch]

A bump to 0.3.0 would probably fit within semver though right? More meaningful error messages seem something worth releasing :)

[necolas]

Ah yes I meant 0.3.

[Kingdutch]

👍

[davidtheclark]

@necolas If the pending pull requests work out, I don't have any other particular changes in mind, so would be eager for a new release.

[necolas]

let me test master out against our code base before i cut a new release. will do it this working week

[necolas]

i dropped HEAD into our codebase, introduced errors, and it failed to report them. so there is something not right with HEAD.

[simonsmith]

A 0.3 release for the latest namespace stuff would be great

[necolas]

sorry my comment suggested the opposite of what is happening. master doesn't report errors properly, which is why i haven't cut a new version

[davidtheclark]

oh, huh ... errors are logging as PostCSS warnings (as discussed in #32 as #36), which means you'd need to be setup to see those (using postcss-log-warnings or something). do you have that in place?

[necolas]

the docs need to mention that, otherwise the plugin doesn't really do anything for you. so this plugin would be dependent on using 'postcss-log-warnings' too?

[MoOx]

It depends on your workflow I guess. If you use webpack for example, you would prefer getting webpack warnings emitted. But yeah, your runner has to show you the messages.

[davidtheclark]

I just added a sentence to Readme --- sorry I didn't know that it would just commit automatically without creating PR :)

Also, if it's really important not to rely on a runner or plugin to log the warnings, we could probably add an option to this plugin that will exit the process and print those warnings immediately.

[necolas]

We currently want the build to fail when the CSS is not properly scoped, otherwise it will end up in master.

The postcss logger plugin worked, but since we're using webpack I end up with 2 sets of warnings – one from postcss, one from webpack. If I use throwError:true, it exits with 1 but you can't tell why. It's not obvious that all the warnings printed before are actually the source of the error.

[MoOx]

@necolas that why the runner need to emit errors via webpack (eg for eslint: https://github.com/MoOx/eslint-loader#errors-and-warning). This will need to be an option added in postcss-loader

[davidtheclark]

I opened #44 to address this.

[necolas]

Another thing to discuss. master produces warnings for selectors like:

.Button--modifier.Button--anotherModifier {}

We have some code like that in a new app. I think that pattern probably is something to avoid, because there are basically side-effects from including 2 modifiers together (should probably be a single modifier). Just wanted to check if there is any disagreement about that.

Thanks

[davidtheclark]

Yeah, I agree that it would probably be better to use a single modifier.

[davidtheclark]

@necolas Anything else you'd like to see done before a new release?

[davidtheclark]

@necolas Any word on this?

[necolas]

tried master on our codebase; looked good. published as 0.3.0. thanks for all the great contributions.