Expose more metadata

[jeddy3]

Firstly, thanks for such a useful tool!

We wrap it in stylelint as the no-unsupported-browser-features rule.

At the moment we pull doiuse's messages apart so we can make them consistent with stylelint's conventions, but this approach is quite fragile.

Would it be possible to expose the browser support results within the doiuse warning? stylehacks (which we wrap as the no-browser-hacks rule) did it like so, and we simply consume this extra metadata like so.

I think something along the lines of the following would be ideal:

result.warn(message, { 
  node: usage, 
  plugin: 'doiuse'
  support: {
    full: [{
      browser: "IE",
      versions: [7, 8, 9]
    }, {
      browser: "Chrome",
      version: [23, 34]
    }],
    partial: [{
      browser: "Opera Mini",
      versions: [1, 2, 3]
    }], 
})

Do you think such a thing would be possible?

[StefanSchwartze]

Sounds very useful to me, I also would need more data like that. The question is, how will the output data then look like… Will we include the full name? Or a slug? I think this needs some discuss.

[jeddy3]

Sounds very useful to me

Good stuff!

Will we include the full name? Or a slug?

I guess the more metadata the better. Can we include both?:

{
  fullName: "Opera Mini",
  slug: "mini",
  versions: [1, 2, 3]
}

[StefanSchwartze]

Of course we can. But I think it would be more consistent to reuse the data provided by the module. Like the following format (described in missing-support.js):

missingData: {
// map of browser -> version -> (lack of)support code
 ie: { '8': 'n' },
 chrome: { '31': 'n' }
}
partialData: {
// map of browser -> version -> (partial)support code
 ie: { '7': 'a' },
 ff: { '29': 'a #1' }
}

With this, it is still possible to find out for example why something is only partially reported, because the support refers to the information provided by "featureData". What do you (and maybe also @anandthakker) think about that?

[anandthakker]

I'm not up to speed on the postcss API, but if result.warn can accept arbitrary metadata I'm all for it.

How about just including something like: https://github.com/anandthakker/doiuse/blob/master/src/doiuse.js#L62-L63

[jeddy3]

How about just including something like:

I'm not too familiar with the internals of doiuse. Could you knockup a quick example of what some data would look like if those two properties were used?

[anandthakker]

@jeddy3 Sure thing, here's an example of the the full object that's output in the lines linked above: https://gist.github.com/anandthakker/83002ac1e12d201fa8c2906990d4978c

You can also see others if you use the -j option with the cli, e.g. doiuse -j my-css.css

[jeddy3]

Thanks for sharing that.

Am I right in thinking that'd we'd need to something similar to contents of missing-support.js and util.js within the stylelint plugin to humanise the data?

If so, as you're already humanising the data for when this tool is used unwrapped, would it be wise to include this humanised data alongside the source from which it's built? e.g.

{
  support: 
    featureData: { ... }
    humanized: {
      full: [{
        browser: "IE",
        versions: [7, 8, 9]
      }, {
        browser: "Chrome",
        version: [23, 34]
      }],
      partial: [{
        browser: "Opera Mini",
        versions: [1, 2, 3]
      }],
    }
  }
}

That seems to expose both the raw results and the humanised data. Two useful things this tool does and would be beneficial to other modules.

[anandthakker]

Hmm, I see what you're saying, but I'm feeling somewhat hesitant to include an additional output here that can be derived without too much extra work from the existing output. Did you see this part of the output?

   "missingData": {
      "opera": {
        "12.1": "n"
      },
      "op_mini": {
        "5.0-8.0": "n"
      }
    },
    "partialData": {
      "safari": {
        "8": "a",
        "9": "a"
      },
      "ios_saf": {
        "8.1-8.4": "a",
        "9.0-9.1": "a"
      },
      "android": {
        "4.2-4.3": "a",
        "4.4": "a",
        "4.4.3-4.4.4": "a"
      },
      "and_uc": {
        "9.9": "a"
      }
    }

It seems to me that the main thing you'd need within stylelint to "humanizing" either partialData or missingData is the formatBrowserName function, which you could simply require with something like var formatBrowserName = require('doiuse/lib/util').formatBrowserName.

@jeddy3 ^ does an approach like this sound viable for you?

[StefanSchwartze]

This is exactly what I meant 5 posts earlier, with featureData + missing/partialData it is possible to get every humanized data, without having to Regex strings or something similiar.

[jeddy3]

@jeddy3 ^ does an approach like this sound viable for you?

Yes, that sounds great.

Thanks for your patience helping me wrap my head around it :)

[clshortfuse]

Closing since issue seems outdated.