Repository: prettier/prettier (JavaScript) — Feature

Issue:
Extend config
Inside an org with a lot of repos we would like to maintain a consistent code style by sharing formatting/linting configuration files. TSLint, ESLint, TypeScript tsconfig etc. all allow this by specifying an `extends` property that points to another config, resolved by node module resolution algorithm. Meaning it's possible to do this:
```json
{
  "extends": "@sourcegraph/tslint-config"
}
```
The rules get shared, but individual rules can still be overridden where it makes sense for only that project. Just passing the path to the config file also prevents editors from detecting that they should use prettier.


Discussion:
I'm currently doing it this way in all of my repos to maintain consistent style:

```js
// prettier.config.js
module.exports = require("prettier-config-ikatyang");
```

The proposed feature (ref: [ESLint config](https://eslint.org/docs/user-guide/configuring#configuration-based-on-glob-patterns)) looks good to me and it seems not hard to implement (use `opts.config`): https://github.com/prettier/prettier/blob/d4768e1336108f2ed672f4d288b1751b9c40c526/src/resolve-config.js#L32
This is already possible though with Object.assign. 

Would/should overrides be inherited?

Prettier doesn't have many options, so having built-in inheritance seems excessive to me.

I agree with @azz on this one; Users should use `Object.assign` (or a deep merge function if that's the behavior they want, instead of shallow) in `prettier.config.js`.
In Node.js 8 you can even use object spread `{...base, override: 12}`.
Since this is super easy to workaround and the inheritance strategy might vary between use cases, let's close this one for now.
Is there a similar "workaround" (I actually like the way with a plain `.js` file) to extend a shared `.prettierignore`?
There isn't. There was a PR to support multiple ignore paths via the CLI in #2720 that could be revived. 
Okay, thank you. Not sure, if this is what I want 🤔  I want to share a `.prettierignore` across projects, not extend the config.

Different question... The whole `.prettierignore` functionality is only accessible via CLI, if I'm not mistaken? I can import `resolveConfig` function, but it doesn't cover the ignore functionality and there is no `resolveIgnoreConfig` or something like that. If I see correctly the CLI uses [`createIgnorer`](https://github.com/prettier/prettier/blob/7b299fb94ecfcec0e57d3f4c82c4ab9ef9e9fd7a/src/cli-util.js#L256) function to read the `.prettierignore` and uses it for filtering [here](https://github.com/prettier/prettier/blob/7b299fb94ecfcec0e57d3f4c82c4ab9ef9e9fd7a/src/cli-util.js#L292). Hmm... looking at it... I guess I need to use the [`ignore`](https://www.npmjs.com/package/ignore) module myself and try to append a `.prettierignore`, if available 🤔
Yeah that's the current way of doing it if you're working with the API. Room for improvement. 
Thank you for clarifying this 👍 
IMHO the @felixfbecker's proposal is quite useful. Other tools like babel, jest, and eslint allows this kind of configuration. We use this approach to share common configuration between projects. The proposed workarounds are only applicable to the `prettier.config.js` file. I thinkg there's no current way to do the same using the `package.json` (or other JSON/YAML config files).

+1 to reopen this issue :)
@davidbarral Then why not switch to `prettier.config.js` if you need this functionality?
Yes. We did it as well and I can only recommend it.

And other projects like Babel support .js as well. This is very nice, because the extend behavior is basically the same across different libs. 
@lydell due to our specific needs we prefer  each and every project to have all its configuration stored in a single file (the package.json). Our projects have several packages (over a dozen) and each one shares the same basic config (beware: not real package names xD):

```
"devDependencies": {
    "shared-tools": "x.y.z"
  },
  "babel": {
    "extends": "shared-tools"
  },
  "jest": {
    "preset": "shared-tools"
  },
  "eslintConfig": {
    "extends": "shared-tools"
  }
```

Now we want to add some shared "prettier" overrides and it would be great to be able to do it the same way we do with other tools without having different config files.

Using the programatic approach would be my choice if I need to customize the config based on environment settings or stuff like that, but it's not the case. 

I see, thanks for explaining!
Sample code:
```typescript
// .prettierrc.js
module.exports = {
    ...require("./your-global-ci-folder/.parent-prettierrc.js"),
    // your overwrite
    printWidth: 140,
    tabWidth: 4
};
```

```typescript
// ./your-global-ci-folder/.parent-prettierrc.js
module.exports = {
    printWidth: 100,
    tabWidth: 2
};
```
Would it be possible to have this issue re-opened or should a new ticket be created?

I work on a team that has a similar use case to @davidbarral's and would like to avoid adding a `prettier.config.js` file to the root of our project just to require our external config...
@TuckerWhitehouse, if you like avoid root file, you can use somethink like this on `package.json`

```json
{
    "scripts": {
        "prettier": "prettier --config ./my/real/.prettierrc",
        "prettier:fix": "prettier --config ./my/real/.prettierrc --write"
    },
}
```

Then, just do `yarn prettier`. I don't recommend this solution because your IDE can't find the correct configuration (if you use any extension).

Also, If you don't put any file on root or package, how can prettier (or IDE) found your config? What is your idea? I can only think of one item in `package.json` :thinking: 
Hey @pablorsk - ideally a field in the `package.json` config, similar to `babel`, `eslint`, `jest`, etc as @davidbarral described.
I'm working on a project that is a mono repo and our configs are stored in parent folder like so:
```
../
├── frontend
│   ├── eslintrc.js
│   ├── prettier.config.js
│   └── tslint.json
├── project1
│   ├── README.md
│   ├── node_modules
│   ├── package.json
│   ├── src
│   ├── test
│   ├── tsconfig.json
│   └── webpack.config.js
└── project2
    ├── README.md
    ├── node_modules
    ├── package.json
    ├── src
    ├── test
    ├── tsconfig.json
    └── webpack.config.js
```
Everything works fine for running our scripts from `package.json` (like @TuckerWhitehouse suggests):
```json
    "scripts": {
        "format": "yarn run format:prettier && yarn run format:eslint && yarn run format:tslint",
        "format:prettier": "prettier --config ../frontend/prettier.config.js --write '**/*.{css,js,jsx,ts,tsx,json}'",
        "format:eslint": "eslint --fix -c ../frontend/eslintrc.js --ignore-path ../frontend/.lintignore '**/*.{js,jsx}'",
        "format:tslint": "tslint --project tsconfig.json --fix -c ../frontend/tslint.json 'src/**/*.{ts,tsx}'"
    }
```

The problem comes with my editor. I'm using vscode and there is currently no way for me to target `../frontend/prettier.config.js` in my editors prettier plugin if `project1` is the root folder of my workspace. I don't really want to create another file at `project1/prettier.config.js` that does the following as @pablorsk suggests:
```js
module.exports = {
  ...require("../frontend/prettier.config.js"),
};
```
@psyrendust as a workaround, you can use a symlink.
@suchipi That would also require me creating a new file in my project folders and potentially needing to exclude them in `.gitignore`, which is not something that I want to do.
🤷
This project is all about predictability and consistency, so an API supporting `extends` and making prettier consistent with eslint, stylelint and babel would be most welcome.
@ikatyang @suchipi - if I were to submit a PR to add config extends functionality with full code coverage and accpetable code quality, would it likely be merged?

I just want to check beforehand, if the team members are against the idea I won’t bother to submit.
Almost certainly!
@j-f1 Awesome! I’ll get on it and submit a PR probably ~late next week~.

Edit Oct 19th, 2018: I am still planning on submitting a PR, just got backed up with work. It will be done soon.
Actually, I disagree- I don't think this needs to be in prettier. See https://github.com/prettier/prettier/issues/3146#issuecomment-342030530
@suchipi what @jayrylan proposes is a way to extend config using json in the package.json, which has nothing to do with the JS config. It cannot be solved using Object.assigns as you stated in #3146. 
I believe that we all agree about the advantages of using JS config over JSON. IMHO the point here is that prettier already supports configuration using a "prettier" key in the package.json (as most other tools do) and seems reasonable to support the "extends" keyword (as most other tools also do). If @jayrylan can provide a patch with good code quality I don't think there is any reason not to merge it. 
> I don't think there is any reason not to merge it

Of course there are reasons.. the first and most important is that once this code is included and this feature is released, we'll have to maintain it forever. We're a small team of volunteers and there's only so much we can do on our spare time.
@duailibe that goes without saying. It's entirely up to you to decide which features you think prettier must support and what's best for the codebase. What I was saying is that feature-wise it makes sense to support the extends functionality.  
Would it be possible to do this inside of cosmiconfig instead?
Ah: https://github.com/davidtheclark/cosmiconfig/issues/40
I’m working on a package that’s an alternative to cosmiconfig with more functionality (but still very lightweight+extendable). If I submit a PR, it would be to change Prettier’s existing config loader with the package I’m writing, so ongoing maintainence would fall on the work I’m doing…which should be updated for the foreesable future, as my company is in the process of publishing over 40 npm packages and our config utility package is used in several of them.

Edit Oct 19th, 2018: I am still planning on submitting a PR, just got backed up with work. It will be done soon.
Heya :hand:  I also did a few works in this field.

_(badges might be broken, because changed my perosnal handle few times, and also started switching to CircleCI but everything is green and working)_

- https://github.com/tunnckoCore/resolve-plugins-sync - browserify/babel/eslint-like config/plugin/transforms resolver
- [In `hela@^2` source (index.js#L100-L127)](https://github.com/tunnckoCore/hela/blob/f78d60daef03d52288bd1c4edd88e30f6b206a36/src/index.js#L100-L127) there's recursive presets/configs resolving, pretty robust and stable, used for a year too
- https://github.com/tunnckoCore/resolve-package 
- [@tunnckocore/pretty-config](https://npmjs.com/package/@tunnckocore/pretty-config) - I believe the published on npm source is currently living at https://github.com/tunnckoCore/hela/tree/v3-major/packages/pretty-config 

Currently supports

```js
const configFiles = [
  '.%src.json', // 1
  '.%src.json6', // 2
  '.%src.yaml', // 3
  '.%src.yml', // 4
  '.%src.js', // 5
  '.%src.mjs', // 6
  '%s.config.js', // 7
  '%s.config.mjs', // 8
  '.%s.config.js', // 9
  '.%s.config.mjs', // 10
  '.%src', // 11 - first try JSON, if fail to parse then fallback to YAML
  'package.json', // 12 - pkg.eslint || pkg.eslintConfig || pkg.config.eslint
];
```

It's very much stable and we are using it for like half year or more, just don't have the time to organize so many repos and things that I'm doing.

More than a year ago started locally the work on `resolve-plugins` (async) but never managed to publish it. Everything is in tons of linked issues around the repos. 
> This project is all about predictability and consistency, so an API supporting extends and making prettier consistent with eslint, stylelint and babel would be most welcome.

Looks like ESLint considers moving away from this because resolving a config through `extends` incurs significant complexity (See https://github.com/eslint/rfcs/pull/9)
@j-f1 I finally got around to publishing the package we're using with my company, it's a drop-in replacement for `cosmiconfig`, in fact it still uses `cosmiconfig` under the hood:

https://www.npmjs.com/package/configomatic

We're using this internally across 40 or so packages, and publicly I'm using it in `packlint` an npm package linter that is published, but I need to write up documentation for:

https://www.npmjs.com/package/packlint

Let me know if you'd like me to send a pull request to switch out `cosmiconfig` for `configomatic`.
cc @prettier/core
Happy to consider using it if we get a "no" [here](https://github.com/davidtheclark/cosmiconfig/issues/1#issuecomment-471232652).
I had an alternate idea which could be considered: Instead of using an `extends` clause, we let the settings be a string referring to a node module instead of an object. You'd just do this in `package.json`:

```json
{
  "prettier": "@scope/prettier-config"
}
```

This removes all complexity around merging configurations, which shouldn't really be necessary. If you want to overwrite some settings just use a `.prettierrc.js` file. 

👍 / 👎 ❓ 
@azz I like it a lot
@azz agree! <3
@azz Excellent! We were considering including a .prettierrc.js in all our projects with the following content:

```js
module.exports = require('@spendesk/prettierrc');
```

Your solution makes things way simpler.
@azz, my concern with that sort of approach is that it's only aimed at package.json usage. 

In the context of prettier supporting multiple programming languages, there are plenty of developers that exclusively use prettier through IDE integration and do not even have a need for a `package.json`. file.

By using configomatic or something similar, developers could still use a plain json file: `.prettierrc.json` .
@jayrylan I think @azz meant that you could use a string as options _anywhere._ For example, .prettierrc.json:

```json
"@scope/prettier-config"
```
@jayrylan Theoretically a `.prettierrc.json` with `"@scope/prettier-config"` would be the same as `"prettier": "@scope/prettier-config"` in `package.json`

EDIT: what @lydell said 😅 
@yacinehmito I'm doing the same, pointing to the eslint config package where I host all the style things.

But still, I don't like to have such files and bloat the root so much with some config files. In a monorepo setup, it might not feel that bad, but otherwise it is, and I was feeling bad about that most of my repos have dozen of things other than `src` dir and package.json.
I've released two packages that you might want to consider.

[resolve-with-prefix](https://github.com/chrisblossom/resolve-with-prefix) - If you wanted to resolve presets similar to `babel` / `eslint`. Examples:

- `@scope/config` -> `@scope/prettier-preset-config`
- `recommended` - > `prettier-preset-recommended`
- `@prettier/recommended` -> `@prettier/preset-recommended`

[ex-config](https://github.com/chrisblossom/ex-config) - Extend configurations (`resolve-with-prefix` is build in). Meant to be used in combination with a config loader, such as [cosmiconfig](https://github.com/davidtheclark/cosmiconfig).

In my opinion, because prettier's config is so basic I think extending configurations is overkill, and @azz's idea about resolving a node module from a string is the best option.
I don't think we should convert strings like that- it makes grepping harder for little value. It also encourages the creation of presets which feels a little silly for prettier.
> It also encourages the creation of presets which feels a little silly for prettier.

But that's the whole point. In an organisation with multiple projects where you want to standardise on a prettier configuration, this is invaluable.

EDIT: Sorry I didn't understand that it was answering to the prefix suggestion.
> it makes grepping harder for little value

What grepping? We don't need anything like that. When it's a string it will just be passed to require, plus if config is found locally (on the project root, or given cwd) merge both. We even don't need to have `extends` solution like other tools in the ecosystem.

> encourages the creation of presets which feels a little silly for prettier.

It already encouraged "a bit more configuration" than strictly been "opinionated", once it introduced semi and the few other options.
I think @suchipi responded to @chrisblossom's comment specifically, not to the idea of being able to re-use a configuration in general.
Yes, @lydell is correct- that was in response to @chrisblossom. Sorry for the lack of clarity.

It makes sense to have organization-wide or monorepo-wide configs but creating a special naming convention would make some public npm names more valuable than others which feels odd because I don't think there is much value in public prettier configs on npm, since we have so few options.

If we encouraged public prettier configs and found that people started all using them for one reason or another (maybe it treats some special files like `.babelrc` differently), then we should probably adopt those as the defaults anyway.

So I don't want to create a situation where public configs have value because encouraging public configs isn't aligned with our design philosophy and I don't want to send mixed signals.

Resolving patch:
diff --git a/CHANGELOG.unreleased.md b/CHANGELOG.unreleased.md
index a88ae9c3b709..4460a0bc86e5 100644
--- a/CHANGELOG.unreleased.md
+++ b/CHANGELOG.unreleased.md
@@ -42,6 +42,35 @@ Examples:
 
 -->
 
+- Config: Support shared configurations ([#5963] by [@azz])
+
+  Sharing a Prettier configuration is simple: just publish a module that exports a configuration object, say `@company/prettier-config`, and reference it in your `package.json`:
+
+  ```json
+  {
+    "name": "my-cool-library",
+    "version": "9000.0.1",
+    "prettier": "@company/prettier-config"
+  }
+  ```
+
+  If you don't want to use `package.json`, you can use any of the supported extensions to export a string, e.g. `.prettierrc.json`:
+
+  ```json
+  "@company/prettier-config"
+  ```
+
+  An example configuration repository is available [here](https://github.com/azz/prettier-config).
+
+  > Note: This method does **not** offer a way to _extend_ the configuration to overwrite some properties from the shared configuration. If you need to do that, import the file in a `.prettierrc.js` file and export the modifications, e.g:
+  >
+  > ```js
+  > module.exports = {
+  >   ...require("@company/prettier-config"),
+  >   semi: false
+  > };
+  > ```
+
 - JavaScript: Add an option to modify when Prettier quotes object properties ([#5934] by [@azz])
   **`--quote-props <as-needed|preserve|consistent>`**
 
diff --git a/docs/configuration.md b/docs/configuration.md
index aaf455904139..14cbbe67adca 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -91,6 +91,35 @@ overrides:
 
 `files` is required for each override, and may be a string or array of strings. `excludeFiles` may be optionally provided to exclude files for a given rule, and may also be a string or array of strings.
 
+## Sharing configurations
+
+Sharing a Prettier configuration is simple: just publish a module that exports a configuration object, say `@company/prettier-config`, and reference it in your `package.json`:
+
+```json
+{
+  "name": "my-cool-library",
+  "version": "9000.0.1",
+  "prettier": "@company/prettier-config"
+}
+```
+
+If you don't want to use `package.json`, you can use any of the supported extensions to export a string, e.g. `.prettierrc.json`:
+
+```json
+"@company/prettier-config"
+```
+
+An example configuration repository is available [here](https://github.com/azz/prettier-config).
+
+> Note: This method does **not** offer a way to _extend_ the configuration to overwrite some properties from the shared configuration. If you need to do that, import the file in a `.prettierrc.js` file and export the modifications, e.g:
+>
+> ```js
+> module.exports = {
+>   ...require("@company/prettier-config"),
+>   semi: false
+> };
+> ```
+
 ## Setting the [parser](options.md#parser) option
 
 By default, Prettier automatically infers which parser to use based on the input file extension. Combined with `overrides` you can teach Prettier how to parse files it does not recognize.
diff --git a/src/config/resolve-config.js b/src/config/resolve-config.js
index 0c3ab33e896a..2f175a79f357 100644
--- a/src/config/resolve-config.js
+++ b/src/config/resolve-config.js
@@ -2,6 +2,7 @@
 
 const thirdParty = require("../common/third-party");
 const minimatch = require("minimatch");
+const resolve = require("resolve");
 const path = require("path");
 const mem = require("mem");
 
@@ -13,6 +14,13 @@ const getExplorerMemoized = mem(opts => {
     cache: opts.cache,
     transform: result => {
       if (result && result.config) {
+        if (typeof result.config === "string") {
+          const modulePath = resolve.sync(result.config, {
+            basedir: path.dirname(result.filepath)
+          });
+          result.config = eval("require")(modulePath);
+        }
+
         if (typeof result.config !== "object") {
           throw new Error(
             `Config is only allowed to be an object, ` +


Test patch:
diff --git a/tests_integration/__tests__/__snapshots__/config-invalid.js.snap b/tests_integration/__tests__/__snapshots__/config-invalid.js.snap
index 90e9857c6236..334c91fa25f6 100644
--- a/tests_integration/__tests__/__snapshots__/config-invalid.js.snap
+++ b/tests_integration/__tests__/__snapshots__/config-invalid.js.snap
@@ -28,7 +28,7 @@ exports[`throw error for unsupported extension (stdout) 1`] = `""`;
 exports[`throw error for unsupported extension (write) 1`] = `Array []`;
 
 exports[`throw error with invalid config format (stderr) 1`] = `
-"[error] Invalid configuration file: Config is only allowed to be an object, but received string in \\"<cwd>/tests_integration/cli/config/invalid/file/.prettierrc\\"
+"[error] Invalid configuration file: Cannot find module '--invalid--' from '<cwd>/tests_integration/cli/config/invalid/file'
 "
 `;
 
diff --git a/tests_integration/__tests__/__snapshots__/config-resolution.js.snap b/tests_integration/__tests__/__snapshots__/config-resolution.js.snap
index c23a07772445..65dc08f3f1cd 100644
--- a/tests_integration/__tests__/__snapshots__/config-resolution.js.snap
+++ b/tests_integration/__tests__/__snapshots__/config-resolution.js.snap
@@ -23,6 +23,9 @@ function f() {
     \\"should have space width 2 despite ../.editorconfig specifying 8, because ./.hg is present\\"
   )
 }
+console.log(
+  \\"should have no semi\\"
+)
 console.log(
   \\"jest/__best-tests__/file.js should have semi\\"
 );
@@ -130,6 +133,7 @@ function f() {
     \\"should have space width 2 despite ../.editorconfig specifying 8, because ./.hg is present\\"
   )
 }
+console.log(\\"should have no semi\\")
 console.log(\\"jest/__best-tests__/file.js should have semi\\");
 console.log(\\"jest/Component.js should not have semi\\")
 console.log(\\"jest/Component.test.js should have semi\\");
@@ -192,6 +196,15 @@ function packageTs() {
 
 exports[`resolves configuration from external files and overrides by extname (write) 1`] = `Array []`;
 
+exports[`resolves external configuration from package.json (stderr) 1`] = `""`;
+
+exports[`resolves external configuration from package.json (stdout) 1`] = `
+"console.log(\\"should have no semi\\")
+"
+`;
+
+exports[`resolves external configuration from package.json (write) 1`] = `Array []`;
+
 exports[`resolves json configuration file with --find-config-path file (stderr) 1`] = `""`;
 
 exports[`resolves json configuration file with --find-config-path file (stdout) 1`] = `
diff --git a/tests_integration/__tests__/__snapshots__/with-config-precedence.js.snap b/tests_integration/__tests__/__snapshots__/with-config-precedence.js.snap
index 9ac3ca80403a..e7a2371cf985 100644
--- a/tests_integration/__tests__/__snapshots__/with-config-precedence.js.snap
+++ b/tests_integration/__tests__/__snapshots__/with-config-precedence.js.snap
@@ -102,6 +102,9 @@ function f() {
     \\"should have space width 2 despite ../.editorconfig specifying 8, because ./.hg is present\\"
   )
 }
+console.log(
+  \\"should have no semi\\"
+)
 console.log(
   \\"jest/__best-tests__/file.js should have semi\\"
 );
@@ -191,6 +194,9 @@ function f() {
     \\"should have space width 2 despite ../.editorconfig specifying 8, because ./.hg is present\\"
   )
 }
+console.log(
+  \\"should have no semi\\"
+)
 console.log(
   \\"jest/__best-tests__/file.js should have semi\\"
 );
diff --git a/tests_integration/__tests__/config-resolution.js b/tests_integration/__tests__/config-resolution.js
index 7d11f0fc182b..797fdee34cff 100644
--- a/tests_integration/__tests__/config-resolution.js
+++ b/tests_integration/__tests__/config-resolution.js
@@ -25,6 +25,12 @@ describe("accepts configuration from --config", () => {
   });
 });
 
+describe("resolves external configuration from package.json", () => {
+  runPrettier("cli/config/", ["external-config/index.js"]).test({
+    status: 0
+  });
+});
+
 describe("resolves configuration file with --find-config-path file", () => {
   runPrettier("cli/config/", ["--find-config-path", "no-config/file.js"]).test({
     status: 0
@@ -262,3 +268,11 @@ test("API resolveConfig resolves relative path values based on config filepath",
     pluginSearchDirs: [path.join(parentDir, "path-to-plugin-search-dir")]
   });
 });
+
+test("API resolveConfig de-references to an external module", () => {
+  const currentDir = path.join(__dirname, "../cli/config/external-config");
+  expect(prettier.resolveConfig.sync(`${currentDir}/index.js`)).toEqual({
+    printWidth: 77,
+    semi: false
+  });
+});
diff --git a/tests_integration/cli/config/external-config/index.js b/tests_integration/cli/config/external-config/index.js
new file mode 100644
index 000000000000..b4639445c510
--- /dev/null
+++ b/tests_integration/cli/config/external-config/index.js
@@ -0,0 +1,1 @@
+console.log("should have no semi");
diff --git a/tests_integration/cli/config/external-config/node_modules/@company/prettier-config/index.json b/tests_integration/cli/config/external-config/node_modules/@company/prettier-config/index.json
new file mode 100644
index 000000000000..4075dbc6e9b3
--- /dev/null
+++ b/tests_integration/cli/config/external-config/node_modules/@company/prettier-config/index.json
@@ -0,0 +1,4 @@
+{
+  "printWidth": 77,
+  "semi": false
+}
diff --git a/tests_integration/cli/config/external-config/node_modules/@company/prettier-config/package.json b/tests_integration/cli/config/external-config/node_modules/@company/prettier-config/package.json
new file mode 100644
index 000000000000..fbd1b33db873
--- /dev/null
+++ b/tests_integration/cli/config/external-config/node_modules/@company/prettier-config/package.json
@@ -0,0 +1,5 @@
+{
+  "name": "@company/prettier-config",
+  "main": "index.json",
+  "version": "0.0.0"
+}
diff --git a/tests_integration/cli/config/external-config/package.json b/tests_integration/cli/config/external-config/package.json
new file mode 100644
index 000000000000..58ab00285687
--- /dev/null
+++ b/tests_integration/cli/config/external-config/package.json
@@ -0,0 +1,3 @@
+{
+  "prettier": "@company/prettier-config"
+}