Roadmap for 0.1.0

[tgfjt]

Hello!

Do you have any Roadmap or something? is it #1?
I'm interested in preparation and implementing of rules.

I'm looking forward to try & counting on stylelint.:smile:

[MoOx]

I think we should

• finish naming convention for rules
• update rules list according to ideas in Rules #1
• add some doc about how to contribute so people can start to work on rules (see workflow #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 Rules #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 :)

[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!