feat: Support packageProp in cosmiconfig

[whitneyit]

This PR adds support for the packageProp in cosmiconfig.

This feature enables developers to remove yet another boilerplate file from their apps.

[Jason3S]

Thank you for the suggestion.

Two things:

1. How about a unit test that verifies the load order assumption? Which will get loaded first package.json or cspell.json?
2. I understand how this could help with reducing the number of files in a project. I had considered turning it on when I added cosmiconfig. My concern was the it would be yet another location for configuration. There also seems to be a trend towards moving away from storing tool related config in package.json. In your opinion, how will this make it easier to use cspell and in what ways might it make it more confusing. Thank you for considering this.

Kind regards,
Jason

[whitneyit]

Hi Jason,

If you want to be more specific about the load order, I would suggest adding package.json to searchPlaces instead of using packageProp. This way, it will loaded in the order specified by the config.

Personally, I wouldn't write a unit test for this. The authors of cosmiconfig have done an amazing job of writing quite a few unit tests verifying the load order 😄

Example unit tests

• https://github.com/davidtheclark/cosmiconfig/blob/18346056c9a7fdf8d7531ea5a998edfb255fc140/test/successful-directories.test.ts#L356
• https://github.com/davidtheclark/cosmiconfig/blob/18346056c9a7fdf8d7531ea5a998edfb255fc140/test/successful-directories.test.ts#L442
• https://github.com/davidtheclark/cosmiconfig/blob/18346056c9a7fdf8d7531ea5a998edfb255fc140/test/successful-directories.test.ts#L612
• https://github.com/davidtheclark/cosmiconfig/blob/18346056c9a7fdf8d7531ea5a998edfb255fc140/test/successful-directories.test.ts#L734
• https://github.com/davidtheclark/cosmiconfig/blob/18346056c9a7fdf8d7531ea5a998edfb255fc140/test/successful-directories.test.ts#L783
• https://github.com/davidtheclark/cosmiconfig/blob/18346056c9a7fdf8d7531ea5a998edfb255fc140/test/successful-directories.test.ts#L850
• https://github.com/davidtheclark/cosmiconfig/blob/18346056c9a7fdf8d7531ea5a998edfb255fc140/test/successful-directories.test.ts#L917

That said, if a unit test is required, I am more than happy to oblige 👍

As for the trend of moving away from config in package.json files, I would say the trend is moving towards shareable configs that only have the extensions placed in package.json.

Something like this:

{
  "commitlint": {
    "extends": "@company/commitlint-config"
  },
  "eslintConfig": {
    "extends": "@company/eslint-config"
  },
  "prettier": "@company/prettier-config"
}

Not that anecdotal evidence counts for much, have a look at this GitHub Search Result. There's about ~1.5 million results of developers using "extends" in a package.json file.

Picking one of the first results at random shows the trend that I am seeing.

As for my personal case, I would want a version similar to:

{
  "cspell": {
    "import": "@company/cspell-config"
  }
}

This will help me, (and presumably others), consolidate configuration.

I don't see this becoming more confusing, I personally find the opposite is true; having numerous boilerplate files.

For example, if you create a new react app using create-react-app, it will create you a package.json file with the following content:

  "eslintConfig": {
    "extends": [
      "react-app",
      "react-app/jest"
    ]
  },
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }

And considering how often React is downloaded, I feel confident saying that a decent percentage of the community is comfortable with some sort of config inside a package.json file.

React's weekly downloads:

[Jason3S]

@whitneyit,

Thank you for the detailed response.

I think your idea of adding it to the searchPlaces is a good idea. That way the order is explicit.

To be clear, I wasn't doubting cosmiconfigs unit testing. Because cspell users will depend upon the order, we need to ensure it is preserved even if at some point in the future, another config library is used. I think adding package.json to searchPlaces makes the order explicit enough, so no need to add a test for that.

Thank you for the help.

[whitneyit]

Ok. I'll update the PR to add it to searchPlaces. Where would you like it? The top of the list perhaps?

[Jason3S]

Ok. I'll update the PR to add it to searchPlaces. Where would you like it? The top of the list perhaps?

I think making it first is the best option. That way someone can import as expected. Importing a package.json file from a cspell.json file seem like the wrong way around.

[Jason3S]

Thank you.