Roadmap for 0.1.0 about stylelint

[MoOx]

I think we should

• finish naming convention for rules
• update rules list according to ideas in #1
• add some doc about how to contribute so people can start to work on rules (see #14)
• release as often as possible so we get feedback asap :)

[tgfjt]

Thank you. I understood!

[MoOx]

That said I will reopen this one so we make things accessible for everyone.

[tgfjt]

That's better:D

[jeddy3]

Shall I create a docs/roadmap.md file and move across the latest rule list from the gist? We can then all edit/PR it and track changes to it.

[jeddy3]

Likewise, I can port over [#14] to doc/adding-a-new-rule.md, if you like?

[MoOx]

I think roadmap should be just opened issue, maybe using github milestone.
But for 14 in docs/ yes :)

[jeddy3]

I've made a start on #14 :)

I think roadmap should be just opened issue, maybe using github milestone.

Yeap agreed, makes sense that the roadmap is handled by issues/milestones.

update rules list according to ideas in #1

Is this something I can help with?

[MoOx]

Maybe we can close #1 and open corresponding issue (then using github assignement to say "I am on it" with a wip label ?) (I will import labels tomorrow morning)

[jeddy3]

Do you mean create an issue for each of the rules within the list? There's a lot, about a 100 I think. Or did you mean something else?

[MoOx]

You r right.
Maybe an recapitulative issue with checkboxs to track progression ?

- [ ] rule-name: short description

• rule-name: short description

We can also just update the existing issue again :)
You should be able to update the desc now that you are a owner.

[jeddy3]

Oh, I didn't realise I could do that now. Neat :)

Updating the existing issue makes the most sense to me:

1. It's the easiest :)
2. At the moment that issue is a great entry point into the project for potential new contributors as:
   1. It shows all the discussions around why we have broken the rules down the way we have.
   2. It contains lots of ideas about how some of the rules might work (e.g. objects for options etc).
3. A lot the rules are just rough ideas at the moment. To me, keeping them in this issue (and in their current form) makes them feel that way. I think if we broke them out into a definitive list using the - [ ] approach then it might give people the wrong idea that they are final, rather than open to welcome discussion.
4. Progress can be roughly tracked by looking at open "New rule: rule-name" issues, the rules already implemented in master and comparing those to the list in #1. I think that'll give people a sense of what needs to be done, without formalising it into a checklist.

How does that sound?

[MoOx]

lgtm !
Adding a checkbox for each rules seems a good way to help tracking global progress.

[davidtheclark]

Great.

[jeddy3]

I've added the checklist to #1. I figured it doesn't formalise things too much as the on-going discussion is laid out directly below it.

What is left to do on this issue before we can get the likes of @tgfjt involved? Wait for @davidtheclark's PR 33 to be merged (with the new testing infrastructure), and then do a release?

[jeddy3]

@MoOx Now that 4 rules are done. Is this a good time to cut a new release?

Quick other question about workflow... one of the rule names is wrong in rules/index.js, is that something I can fix directly in master or should I be creating pull requests for things like that too? Thanks.

[davidtheclark]

Seems to me that typos like that you should feel free to just fix.

[jeddy3]

Done :)

[MoOx]

If you want, you can ping owners (us) from a commit message by adding a ref like "@stylelint/owners"

[MoOx]

I will make a global checkup and cut a new release tomorrow when I wake up !

[MoOx]

Is this a good time to cut a new release?

I think we should make adjust some stuff for #38 and #40 before doing a release.

And @davidtheclark can you add minimal documentation for the rules you created like @jeddy3 does for this one https://github.com/stylelint/stylelint/tree/master/src/rules/declaration-no-important ?
That would be great so I can generate a website from those files :)

[jeddy3]

Yeap, lets wait on #38 and #40

[MoOx]

#40 has been reopened so should we wait for 0.1.0 ?
We can discuss on that on gitter if you want.

[jeddy3]

@davidtheclark & @MoOx I'm almost done documenting the rules so far (see: #92). BTW @davidtheclark, going through all your tests, for the documentation, really made me appreciate just how much work you've done on this project already! Thanks again!

I think the generated rules list ( #137 ), website ( #6 ) and logo ( #7 ) aren't required for 0.1.0. What do you guys think about cutting a release with what we have? A couple of people have already expressed an interest (on here and in gitter) in using what we have, and I think it would be good to get some other real-world feedback on what we've got already. Perhaps it'll also encourage a few people to help out with some of the status: pr welcome issues :)

I think the only outstanding issue for 0.1.0 is whether we blend rule-set- and declaration-block rules ( #91 )?. I'm happy to refactor the code and update the docs if we decide to go ahead with this.

Oh, I'll need to finish up the documentation in #92 before the release, which I'll hopefully do tomorrow.

What do you guys think?

[davidtheclark]

Great job working through those docs, @jeddy3.

I am probably going to take a crack in a few minutes at finishing some more "separation" rules (*-line-before). But I think at this point there's no reason to wait on any particular rules before releasing something.

I think it might be a good idea for us to cut a release and then try it out ourselves on some real CSS projects before we go announcing on Twitter that we want people to have at it. Despite having written so many rules and tests I haven't tried much real-world experiment yet ... have either of you?

In fact, now that I think more about it, I realize I'm a little wary: after we have given it a try I'd be happy to individually notify people who know the state of the project and want to help out in development (not just consume it as an end user); but I'm wondering if it might be counter-productive to "publicize" a release (as much as we're able) until we have generated docs, we're sure that what we do have is working as expected, the settings and severity levels work, etc. Because I'd be worried about the project getting attention early on then people figuring out it's not ready for prime-time and writing it off. Does that concern make sense?

[MoOx]

Website & docs are totally not required for a start, only for 1.0 :).
We can push when you feel the need.

[jeddy3]

Because I'd be worried about the project getting attention early on then people figuring out it's not ready for prime-time and writing it off. Does that concern make sense?

Yeap, it does.

after we have given it a try I'd be happy to individually notify people who know the state of the project and want to help out in development (not just consume it as an end user).

Agreed. They seem like the best next steps.

1. Give it a try ourselves.
2. Then we notify the likes of tgfjt, ferdinandsalis and YuliaTsareva (who've all expressed an interest) that the project is at an early stage, but we're now ready for them to help out with testing the rules and helping with the development.

Despite having written so many rules and tests I haven't tried much real-world experiment yet ... have either of you?

I've tried on a few occasions to give it a go myself, but I've run into difficulties (I'll create a separate issue for this). I'm keen to run what we have against my current project (via making a rules config that enforces as much of the SUITCSS STYLE guidelines as possible) so we can validate our choice of rule names and their implementations.

At the moment I'm manually copying the generated stylelint js files into the node_modules/stylelint directory of my project. Is there a better way? Would the ideal be for us to be able to grab master or a branch from github using npm install stylelint/stylelint, but I wasn't sure how this works with the babel transpiler step? @MoOx Any thoughts on the best approach here?

but I'm wondering if it might be counter-productive to "publicize" a release (as much as we're able) until we have generated docs, we're sure that what we do have is working as expected, the settings and severity levels work, etc.

I agree. I'm OK with going step-by-step with this: we test it first, then a few individuals and only then we can decided which of the remaining issues (severities/extend, generated docs/website, accurate line numbers etc) should be tackled before we publicise a release (on twitter and the like).

Website & docs are totally not required for a start, only for 1.0 :).

SGTM. I'll add milestones to the appropriate issues :)

[MoOx]

In order to handle the babel step you will need to do something like

$ npm install stylelint/stylelint && cd node_modules/stylelint && npm i && cd ../..

[jeddy3]

Thanks @MoOx!

I've (temporarily) added the src directory to the package.json files as they are needed if stylelint is installed from the github repo.

[MoOx]

We should provide it to allow this usage anyway. So it won't be temporarily :)

[davidtheclark]

Life is extremely hectic for me right now (just moved houses), so please don't wait on me for anything. Over the next week I'll poke in when I have the chance (and can stay awake). Thanks for getting this going!

[jeddy3]

after we have given it a try

I figured I'd keep you two apprised of how I'm getting on with this. It's pretty exciting stuff :)

I've been running, with great success, a SUITCSS styleguide config against a few SUITCSS-based projects I worked on. The config currently looks like:

"rules": {
  "at-rule-empty-line-before": [2, "always"],
  "at-rule-no-vendor-prefix": 2,
  "block-closing-brace-newline-after": [2, "always"],
  "block-closing-brace-newline-before": [2, "always-multi-line"],
  "block-closing-brace-space-before": [2, "always-single-line"],
  "block-no-empty": 2,
  "block-opening-brace-space-before": [2, "always"],  
  "block-opening-brace-newline-after": [2, "always-multi-line"],
  "color-no-invalid-hex": 2,
  "comment-empty-line-before": [2, "always-except-inline"],
  "declaration-bang-space-after": [2, "never"],
  "declaration-bang-space-before": [2, "always"],
  "declaration-colon-space-after": [2, "always"],
  "declaration-colon-space-before": [2, "never"],
  "declaration-comma-space-after": [2, "always"],
  "declaration-comma-space-before": [2, "never"],
  //"declaration-semicolon-newline-after": [2, "always-multi-line"],
  "declaration-semicolon-space-before": [2, "never"],
  "function-calc-no-unspaced-operator": 2,
  "function-comma-space-after": [2, "always"],
  "function-comma-space-before": [2, "never"],
  "function-parentheses-inside-space": [2, "never"],
  // "function-space-after": [2, "always"],
  "function-token-no-space": 2,
  "function-url-quotes": [2, "double"],
  "indentation": [2, {
    space: 2,
    block: "always",
    value: "always",
  }],
  "media-feature-colon-space-after": [2, "always"],
  "media-feature-colon-space-before": [2, "never"],
  "media-feature-range-operator-space-after": [2, "always"],
  "media-feature-range-operator-space-before": [2, "always"],
  "media-query-parentheses-inside-space": [2, "never"],
  //"no-eol-whitespace": 2,
  //"no-missing-eof-newline": 2,
  "number-leading-zero": [2, "always"],
  "number-no-trailing-zeros": 2,
  "property-no-vendor-prefix": 2,
  "property-value-no-vendor-prefix": 2,
  "root-no-standard-properties": 2,
  "rule-nested-empty-line-before": [2, "always-multi-line"],
  "rule-trailing-semicolon": [2, "always"],
  "selector-combinator-space-after": [2, "always"],
  "selector-combinator-space-before": [2, "always"],
  "selector-delimiter-newline-after": [2, "always"],
  "selector-delimiter-space-before": [2, "never"],
  "selector-no-vendor-prefix": 2,
  //"selector-pseudo-element-colon-notation": [2, "double"],
  "selector-root-no-composition": 2,
  //"string-quotes": [2, "double"],
}

The vast majority of the rules are working a treat! Just a few, the commented-out ones, seem to be misbehaving and I'll create issues for these next.

I took a piece of SUITCSS-styleguide-compatible CSS:

:root {
  --color: pink;
}

@keyframes { 0% { top: 0; } }

/* comment */

.selector-1,
.selector-2 + .selector-3,
.selector-4[type="text"] {
  background: linear-gradient(#fff, rgba(0, 0, 0, 0.8)); /* 2 */
  color: color(rgb(0, 0, 0) lightness(50%));
  content: "x";
  transition: all 3s;
}

.selector-a,
.selector-b {
  background-image: url("x.jpg"), linear-gradient(#f3c, #4ec);
}

.selector-c::before {
  color: pink;
}

:fullscreen .selector-1 {
  background-image: none;
}

.selector-i { top: calc(1px + 2px); }
.selector-ii { width: 10%; }

@media (min-width: 60em) {
  .selector-ii { width: 20%; }
}

@media (max-width >= 600px) {
  .selector-ii { width: 30%; }
}

and turned it into this monstrosity (designed to trigger a warning at least once for every rule):

@-webkit-keyframes { 0% { top: 0; } }
/* coment */
:root,
.selector-1 {
  color: pink;
}

.selector-1 ,.selector-2+.selector-3,
.selector-4[type='text'] {
background :-webkit-linear-gradient(#ff,rgba(0, 0, 0, .8000)) ;
    color: color (rgb(0, 0, 0)lightness(50%));  
    content: 'x';-moz-transition: all 3s
} .selector-a,
.selector-b {
  background-image: url(x.jpg),linear-gradient(#f3c , #4ec );
  box-shadow: 0px 1px 1px #000;
}

.selector-c::before {
  color: pink;
}

:-webkit-full-screen .selector-1 {
  background-image: none;
}

.selector-i{top: calc(1px+ 2px);}.selector-ii { width: 10.0%; }


.selector-ii {}

@media ( min-width :60em ) {
.selector-ii { width: 20%; }
}
@media (max-width>=600px) {
  .selector-ii { width: 30%; }
}

It produces this neat console output:

# postcss-log-warnings

css\input.css
35:1    Expected empty line before at-rule (at-rule-empty-line-before) [stylelint]
1:1     Unexpected vendor-prefixed at-rule "@-webkit-keyframes" (at-rule-no-vendor-prefix) [stylelint]
8:1     Expected newline after "}" (block-closing-brace-newline-after) [stylelint]
27:1    Expected newline after "}" (block-closing-brace-newline-after) [stylelint]
27:1    Expected single space before "}" of a single-line block (block-closing-brace-space-before) [stylelint]
30:1    Expected single space before "}" of a single-line block (block-closing-brace-space-before) [stylelint]
30:1    Unexpected empty block (block-no-empty) [stylelint]
27:1    Expected single space before "{" (block-opening-brace-space-before) [stylelint]
10:1    Invalid hex color "#ff" (color-no-invalid-hex) [stylelint]
2:1     Expected empty line before comment (comment-empty-line-before) [stylelint]
10:1    Expected single space after ":" (declaration-colon-space-after) [stylelint]
10:1    Unexpected space before comma ":" (declaration-colon-space-before) [stylelint]
15:3    Expected single space after comma within a declaration value (declaration-comma-space-after) [stylelint]
10:1    Unexpected space before ";" (declaration-semicolon-space-before) [stylelint]
27:13   Expected single space before "+" operator within calc function (function-calc-no-unspaced-operator) [stylelint]
10:1    Expected single space after comma within a function (function-comma-space-after) [stylelint]
15:3    Unexpected space before comma within a function (function-comma-space-before) [stylelint]
15:3    Unexpected space before ")" of a function (function-parentheses-inside-space) [stylelint]
11:5    Unexpected space between function name and "(" (function-token-no-space) [stylelint]
15:3    Expected double quotes around url argument (function-url-quotes) [stylelint]
33:1    Expected indentation of 2 spaces at line 33 (indentation) [stylelint]
10:1    Expected indentation of 2 spaces at line 10 (indentation) [stylelint]
11:5    Expected indentation of 2 spaces at line 11 (indentation) [stylelint]
12:2    Expected indentation of 2 spaces at line 12 (indentation) [stylelint]
32:1    Expected single space after ":" in media feature (media-feature-colon-space-after) [stylelint]
32:1    Unexpected space before ":" in media feature (media-feature-colon-space-before) [stylelint]
35:1    Expected single space after range operator in media feature (media-feature-range-operator-space-after) [stylelint]
35:1    Expected single space before range operator in media feature (media-feature-range-operator-space-before) [stylelint]
32:1    Unexpected space before "(" of a function (media-query-parentheses-inside-space) [stylelint]
32:1    Unexpected space before ")" of a function (media-query-parentheses-inside-space) [stylelint]
10:1    Expected a leading zero for fractional value less than 1 (number-leading-zero) [stylelint]
10:1    Unexpected trailing zero(s) (number-no-trailing-zeros) [stylelint]
27:49   Unexpected trailing zero(s) (number-no-trailing-zeros) [stylelint]
12:15   Unexpected vendor-prefixed property "-moz-transition" (property-no-vendor-prefix) [stylelint]
10:1    Unexpected vendor-prefixed property value "-webkit-linear-gradient" (property-value-no-vendor-prefix) [stylelint]
5:3     Unexpected standard property "color" in rule set applied to ":root" (root-no-standard-properties) [stylelint]
8:1     Expected a trailing semicolon (rule-trailing-semicolon) [stylelint]
30:1    Expected a trailing semicolon (rule-trailing-semicolon) [stylelint]
8:1     Expected single space after combinator "+" (selector-combinator-space-after) [stylelint]
8:1     Expected single space before combinator "+" (selector-combinator-space-before) [stylelint]
8:1     Expected newline after selector delimiter (selector-delimiter-newline-after) [stylelint]
8:1     Unexpected space before selector delimiter (selector-delimiter-space-before) [stylelint]
23:1    Unexpected vendor-prefixed selector ":-webkit-full-screen" (selector-no-vendor-prefix) [stylelint]
3:1     Unexpected composition of the ":root" selector (selector-root-no-composition) [stylelint]

Where as the SUITCSS styleguide compatible version produces no warnings.

Good stuff :)

I'll make a start on creating those issues next...

[davidtheclark]

Very nice!

[MoOx]

So guys tell me when you think it's time, and also, give me you npm login so I can give you the right to publish. We will just need to be sure that we will use the same command/function to tag + publish + github release :)

[jeddy3]

So guys tell me when you think it's time

Will do. I'm still plugging-in @davidtheclark new rules into my test bed. A couple more issues have popped up (which I'll create tickets for). After that, I think it'll be about the right time to notify a few individuals about how they can help us test the rules and plugin (they can do this via installing from master). After than, I think we'll be about ready for a npm publish.

give me you npm login

I'm also "jeddy3" on npm.

We will just need to be sure that we will use the same command/function to tag + publish + github release :)

Sounds good. I'll follow your lead on this one :)

[davidtheclark]

I'm davidtheclark on npm.

[jeddy3]

@stylelint/owners A quick update on my progress on this...

I figured there was no better place to dog-food our own linter than on the project's website. I've quickly put together a version of the site that is lintable. It's an abomination of hacky browser JavaScript, but it's just enough for us to dog-food the linter. We can metalsmithify and reactify the website later down the line, which will add lots of necessary goodness like a working back button, an indexable site and a web-based linter. At the moment, and I'll stress this again, it's just a hacky thing that I knocked up so we'd have some css to run the linter against :)

You can see it here:
https://stylelint.github.io/preview.html

As an aside; it's nice to see the documentation (especially for the rules) coming to life :)

Most important is the linter config, which is here:
https://github.com/stylelint/stylelint.github.io/blob/master/scripts/lint-css.js

It's enforcing the SUITCSS styleguide at the moment.

The only rule that is misbehaving is number-zero-length-no-unit. I'm going to create a PR for that next. Everything else is working as expected!

You can see for yourself by cloning the repo, running npm install and then npm run lint-css.

I'll be adding any new rules to the config as they are merged into master.

Ref #6

[davidtheclark]

Looks like a fantastic start.

[jeddy3]

@davidtheclark Thanks for fixing number-zero-length-no-unit! Now master, correctly, does not flag up any warnings against the stylelint.io css :)

[jeddy3]

@davidtheclark & @MoOx I think we're almost ready to notify a few individuals. I think deciding on the name changes in #178 is the last remaining thing to do. I'll then make any changes that come out of that, and then I think we're good to go :)

What do you guys think?

[MoOx]

lgtm. Sorry to not be that much involved this days. I will still handle the website (I am still improving my current engine on cssnext website)

[davidtheclark]

@jeddy3 Have we corrected all the rules that were misbehaving in your trials? I think that sometime within the next week I'm going to try to integrate this into my process at work and see how it goes.

[jeddy3]

@davidtheclark Yeap, everything I've spotted so far has been addressed. Latest config at: https://github.com/stylelint/stylelint.github.io/blob/master/scripts/lint-css.js . It'll flag no warnings against the website CSS once #199 is merged into master.

I think that sometime within the next week I'm going to try to integrate this into my process at work and see how it goes.

Sweet! Shall we hold off on notifying a few individuals until you've done this, or are you happy if they try it out at the same time?

[davidtheclark]

I'm happy to have others try it out at the same time if you like how it's
going.

On Thu, Jun 18, 2015 at 7:59 AM, jeddy3 [email protected] wrote:

@davidtheclark https://github.com/davidtheclark Yeap, everything I've
spotted so far has been addressed. Latest config at:
https://github.com/stylelint/stylelint.github.io/blob/master/scripts/lint-css.js
. It'll flag no warnings against the website CSS once #199
#199 is merged into master.

I think that sometime within the next week I'm going to try to integrate
this into my process at work and see how it goes.

Sweet! Shall we hold off on notifying a few individuals until you've done
this, or are you happy if they try it out at the same time?

—
Reply to this email directly or view it on GitHub
#15 (comment).

[davidtheclark]

Should we tag another release for these people? Was that part of the plan?

[jeddy3]

I dunno. I'm not sure what's best, like to previously said, to manage expectations. I had originally thought just to suggest using master. Or does that unnecessarily complicate things for them?

[jeddy3]

Thinking it about it some more... lets make things as simple as possible and cut the 0.1.0 npm release for them. We can manage expectations through the notification. Thoughts?

[davidtheclark]

If it's a select group of people who know that they are doing a "trial
run", I think there's nothing wrong with telling them to use master. It
might even keep expectations more clear than having a release. Let's do
that.

On Thu, Jun 18, 2015 at 9:20 AM, jeddy3 [email protected] wrote:

I dunno. I'm not sure what's best, like to previously said, to manage
expectations. I had originally thought just to suggest using master. Or
does that unnecessarily complicate things for them?

—
Reply to this email directly or view it on GitHub
#15 (comment).

[davidtheclark]

Ha! Just saw your comment. I'm fine with that, too. Clarify expectations
with a message and it should be good.

On Thu, Jun 18, 2015 at 9:36 AM, David Clark [email protected]
wrote:

If it's a select group of people who know that they are doing a "trial
run", I think there's nothing wrong with telling them to use master. It
might even keep expectations more clear than having a release. Let's do
that.

On Thu, Jun 18, 2015 at 9:20 AM, jeddy3 [email protected] wrote:

I dunno. I'm not sure what's best, like to previously said, to manage
expectations. I had originally thought just to suggest using master. Or
does that unnecessarily complicate things for them?

—
Reply to this email directly or view it on GitHub
#15 (comment)
.

[jeddy3]

Oops! Now you've got me second-guessing myself :)

Lets stick with master for now so we can iterate quickly without having to tag and do releases for them. We can release in a week or something once we've ironed out anything that crops up :)

[jeddy3]

@YuliaTsareva @ferdinandsalis @tgfjt @m-allanson

Hi. We're gearing up for the first release of stylelint and, as the four of you expressed an early interest in the project, we thought we'd ask you for a hand trying out what we have so far.

It's still early days, but we've made a start on over 70 of the rules, including all of the whitespace ones. There's still lots to do though e.g. reporting accurate line numbers and starting on another 30 rules we've got lined-up, but we think there's enough here for the linter to be useful.

So if you're interesting in giving it a go you'll need to install the linter as follows (as we're working off master and using a transpiler):

$ npm install stylelint/stylelint && cd node_modules/stylelint && npm i && cd ../..

We're using the linter on the WIP stylelint.io website CSS. We're using the node API approach, but you can use any of the postcss runners (like gulp-postcss) if you'd prefer. There's an example config in the stylelint.io repo that enforces the SUITCSS styleguide.

Were the four of you planning to use the linter to enforce your own styleguide or do you follow a 3rd party ones? It'd be interesting to know as we were discussing whether to provide presets for some 3rd party ones or not.

The rules we've started are documented here. The documentation is a bit rough-around-the-edges, so please flag up any issues you run into with it.

We plan to tag releases, for everyone's convenience, once we've finished trialling the rules we have so far. Hopefully that'll be in a week or so :)

Please don't hesitate give us a shout here if you run into any trouble. Also, feel free to create a issue or pull request for any problems you encounter. Likewise, feel free jump in and tackle any of the remaining rules that might interest you! :)

Thanks!

@davidtheclark @MoOx Anything you guys want to add?

[MoOx]

I will integrate that in my workflow as soon as I will implement a easy way to plugin this. See postcss/postcss-import#45

[MoOx]

To answer, I don't have anything to add, I think the current state of the project is pretty awesome. We need indeed some tests before starting to push releases in order to avoid breaking changes + long changelog ^^

[jeddy3]

@MoOx That addition to postcss-import sounds great!

[m-allanson]

@jeddy3 I've tried this on my current (small) project. I'm using the SUITCSS conventions and running stylelint with your provided example config (via npm run). It seems to work very well!

I've opened issues for a couple of things - of the remaining problems I've had one will be fixed by #222. The only other issue was that the disable string /* stylelint-disable */ didn't seem to be having any effect on my linting output, based on #105 I believe it should. I'll hopefully have time to look into this later in the week and will raise an issue if the problem doesn't appear to be a user mistake.

[jeddy3]

Thanks for trying it out! Your feedback has been a great help :)

[davidtheclark]

Thanks from me, too, @m-allanson. I may have solved the disabling problem with another PR that should be merged soon.

[MoOx]

@jeddy3 @davidtheclark I just added you as owners of the stylelint module on npm. Thanks for all the work you are doing :)
I will still try to work on the website asap (current status: too many bugs to fix everywhere ^^)

[jeddy3]

I just added you as owners of the stylelint module on npm.

Thanks!

I will still try to work on the website asap (current status: too many bugs to fix everywhere ^^)

I think we've got something viable in http://stylelint.io/preview.html (it's very hacky, but I think it's OK for now - at least for version 0.1.0), so there's no real rush on the website :) The cssnext.io metalsmith and react stuff looks great though and it'd be fab to see it used for the stylelint docs in future, but only when you've no more bugs to squash elsewhere :)

[MoOx]

I think we've got something viable in http://stylelint.io/preview.html

Yeah totally fine. No rush like you said. Feel free to push that as index.html ^^

[davidtheclark]

FYI, I will be in a cabin in the woods for a week or so starting tomorrow. So I may be incommunicado. If I don't respond to something that's why. @jeddy3 feel free to do anything related to 0.1.0 without waiting on input from me :)

[jeddy3]

I started a new (short) contract yesterday, so I won't be able to do much on stylelint this week. Lets get 0.1.0 out when you get back. Enjoy your week in the woods :)

[tgfjt]

I've tried on some situations. It totally seems to be great!

[jeddy3]

Great to hear! I think we're looking good for a release next week :)

[tgfjt]

I'd also like to user "stylelint-config-suitcss"! 👍

[davidtheclark]

I'm back. I don't see any issues that need fixing, so maybe it's time to release 0.1.0 and ask some people to try it out? I don't know if I feel good about trying to get much attention until #133 is resolved ... but the more early adopters we can get to try it the better.

[ntwb]

Hey, I've been watching this repo for approximately the last month, hope you've all enjoyed your recent well deserved time off, I know I have had a tidier inbox ;)

Anyways, I just thought I'd add a comment here to saying that I think what your doing is awesome, there's been quite a lot of said awesome flow throw my inbox this past month. I plan on and have already begun some initial tests to add this to the WordPress project, so I'm really looking forward to the 0.1.0 release. (And yeah #133 would be nice)

[jeddy3]

@davidtheclark Welcome back! I hope you had a nice week :)

I don't know if I feel good about trying to get much attention until #133 is resolved

Agreed. A quiet release makes sense to me. We can also add a little note to the top of the README, perhaps replacing the current "See the 0.1.0 roadmap issue for details of our progress towards the first release", which reads "Note: see issue #133 for details of our progress towards more accurate line numbers". At least that way early adopters' expectations will be set when they come to use 0.1.0 and they stumble into some inaccurate line numbers. What do you think?

so maybe it's time to release 0.1.0 and ask some people to try it out?

I reckon so :) If I make the README file amends, are you able to run through the release process?

@ntwb Glad you're finding the linter useful :) Is it the Wordpress CSS Coding Standards that you'll be checking against? I had a quick look though it and I think the linter will check most of it. Let us know if there's something in the standards that's missing though and we'll look into ways to include it in the linter.

[ntwb]

Jeddy3 wrote:

Is it the Wordpress CSS Coding Standards that you'll be checking against?

Yes, that's it :)

I had a quick look though it and I think the linter will check most of it. Let us know if there's something in the standards that's missing though and we'll look into ways to include it in the linter.

Agreed, I think most things are good to go, and for sure I'll let you know if we hit any hurdles :)

[davidtheclark]

Sounds good @jeddy3. I could make the release tonight.

[MoOx]

[jeddy3]

ntwb wrote:

Yes, that's it :)

Good stuff. Those standards seem like a great candidate for a shareable config. Give me a shout if you want me to setup a stylelint-config-wordpress repo in the stylelint org and give you access to it :)

But if you're happy working with your own local config, well that's totally groovy too :)

[ntwb]

Jeddy3 wrote:

Good stuff. Those standards seem like a great candidate for a shareable config. Give me a shout if you want me to setup a stylelint-config-wordpress repo in the stylelint org and give you access to it :)

But if you're happy working with your own local config, well that's totally groovy too :)

This sounds like a great idea, and for sure will help out the WordPress sub-projects I know that will follow suit and also begin using stylelint.

The one thing I want to just note is that getting this into WordPress Core is not guaranteed, I'm one of the build tools maintainers for WordPress so things look promising, just wanted to say that nothing is a sure thing is all ;)

[davidtheclark]

I just released 0.1.0.

As a trial, I integrated into a project I've been working on -- and everything went smoothly. Let me know if the same doesn't happen for you.

[tgfjt]

🎉

[ntwb]

💥

[magsout]

I just released 0.1.0.

👍 gooood job @stylelint/owners

[MoOx]

@davidtheclark @jeddy3 is the CHANGELOG up to date ?
I would be nice to make a github release after the tag/npm publish. I currently use this command to make this thing easy (take part from the changelog that fit the current version in package.json and edit the tag on github to make this a release) https://github.com/MoOx/setup/blob/master/bin/npmrelease
The nice thing is that watchers are being notified via github with the changelog.
Note: my script work with tag that does not include the "v" (like 0.1.0, not v0.1.0) so maybe if you consider using this, you should drop the v from tag names.
Otherwise this can be done by hand but it's more painful.

I will tweet about this release.

[MoOx]

https://twitter.com/stylelint/status/619112313413611520

[davidtheclark]

I will try to check the CHANGELOG.

I did make a release, but didn't add annotation so it is not good reading :) I can manually fix that for this release and then we can try the script next time. Do you normally include it in a repo or just use it from your computer?

[MoOx]

This command can be executed after the tag creation, so you might be able to use it even now (if you rename v0.1.0 to 0.1.0 or if you adjust the script).

I use npmpublish + npmrelease which are 2 commands (on to test/publish/tag and the other to transform the tag to a github release).

I use them from my computer (dotfiles) but maybe I can push those to npm or something. Maybe just the 2, cause my npmpublish command is pretty simple.

I already see some alternative that generate changelog+github release from commits but I don't find it's accurate most of the time (some commits, like refactoring or pure doc have nothing to do in changelog for me).

[MoOx]

@davidtheclark fyi, I finally published my npmpublish and npmrelease command.
If you are using those (prepare changelog + bump version in package.json by hand + npmpublish (& npmrelease), you can probably now replace npmpublish by this:

get npmpub(lish) && github-release-from-changelog as dev deps

$ npm i -D npmpub github-release-from-changelog

add a script this way (in package.json "scripts" section)

{
  "scripts": {
    "release": "npmpublish && github-release-from-changelog"
  }
}

So now you can prepare changelog+bump package by hand and then just do $ npm run release.

2cents advice try this on a small repo first, just in case (it's the same code, but your never know, it's still fresh).

I used those packages themselves to publish and release themselves as a test ^^

• https://github.com/MoOx/npmpublish/blob/32d98aef0c7b1e5d3d46d2b6cfe63995557c6648/package.json#L27
• https://github.com/MoOx/github-release-from-changelog/blob//2552883dfeec19b2088008a51a33842c24da8197/package.json#L29

[jeddy3]

Looks groovy thanks. I'm going to flag this up in another issue as I'm afraid it'll get missed here.

[davidtheclark]

Thanks @MoOx!