Remove huge JavaScript parsers from Prettier core to reduce package size

[sosukesuzuki]

#13818 (comment)

Overview

Prettier package includes too many JavaScript parsers. And it makes the size of the npm package much larger than it needs to be.

So, I propose the change to keep only the limited parsers that are really needed in the core, and provide and maintain the rest as external parser plugins.

How

Only babel, babel-flow, and babel-ts remain in the Prettier core. Other parsers typescript, acorn, espree, meriyah, and flow are provided as external plugins(with names like @prettier/plugin-parser-typescript for example).

This will also make it easier to introduce new parsers. For example, we could provide a hermes and SWC as a JavaScript parser for Prettier.

1. monorepo

With this change we will have to publish multiple packages(I thinks parsers packages version should be synchronized with the core).

Also we need to share common postprocess and test cases for JS parsers.

So I think we can introduce monorepo by Yarn workspace like below:

.
│   ├── packages
│   │   ├── prettier
│   │   ├── prettier-plugin-parser-typescript
│   │   ├── prettier-plugin-parser-meriyah
│   │   ├── prettier-plugin-parser-acorn
│   │   ├── prettier-plugin-parser-flow
│   │   └── prettier-plugin-parser-espree
│   ├── internals
│   │   ├── eslint-plugin-prettier-internal
│   │   ├── util-js-parser-postprocess
│   │   └── test-cases-js-parsers
│   └── apps
│   │   └── website

(There may be other things that should be in the internal package that I forgot.)

This is a difficult change to revert and should be discussed thoroughly.

2. multiple repositories

Just maintain and develop each parser as a separate repository

e.g. github.com/prettier/plugin-parser-typescript, github.com/prettier/plugin-parser-meriyah, etc

---

What do you think?

[fisker]

I prefer separate Node.js version and standalone version first, because all parsers(plugins/*.mjs) I may use someday. But I don't think I'll ever use the UMD version.

BTW, the package name should be

- @prettier/plugin-parser-typescript
+ @prettier/plugin-typescript

[sosukesuzuki]

What is standard version?

BTW, the package name should be

The name @prettier/plugin-typescript makes it sound like it even includes the print algorithm. In fact, only the parser is included there.

[fisker]

What is standard version?

standalone , sorry.

[fisker]

only the parser is included there.

Printer is not required to be a plugin, and printer can be included if we publish plugins separately.

[fisker]

For the file structure, I prefer

.
├── packages
│   ├── core (will publish as `@prettier/core`)
│   ├── cli (will publish as `@prettier/cli`)
│   ├── document (will publish as `@prettier/doc` or `@prettier/document`)
│   ├── js 
│   │   ├── typescript  (will publish as `@prettier/plugin-typescript`)
│   │   ├── meriyah  (will publish as `@prettier/plugin-meriyah`)
│   │   ├── ...  (will publish as `@prettier/plugin-...`)
│   │   ├── printer  (will publish as `@prettier/plugin-estree-printer`, other plugins will include it as dependency or bundle it without publishing this plugin)
│   │   └── tests  (to test all js plugins)
│   ├── markdown  (will publish as `@prettier/plugin-markdown`)
│   ├── css  (will publish as `@prettier/plugin-css`)
│   ├── yaml  (will publish as `@prettier/plugin-yaml`)
│   └── ...other plugins
├── scripts
├── website
└── ...

Except for the js plugins, they can even still stay in src/language-xxx/, nobody says package has to be inside packages/, add a package.json in those dirs will work.

[fisker]

Make our codebase monorepo may also break "install-from-github" feature, I don't think workspace: in dependency will work.

[sosukesuzuki]

With the structure you showed, users will have to use @prettier/core and @prettier/cli when using Prettier? Ideally, when using Prettier, users would just need to install prettier.

[fisker]

No, we'll add them to prettier package's dependencies. But they can be installed separately. See https://unpkg.com/browse/jest@29.3.1/package.json

[sosukesuzuki]

Okay, if we provide packages in the style of Jest, no problem.

[liuxingbaoyu]

Make our codebase monorepo may also break "install-from-github" feature, I don't think workspace: in dependency will work.

Just a personal opinion:

if we go ahead with #6286 in the future, this will have the same impact.
At the same time, with the increasing number of complex projects in the JS world, "install-from-github" may not be so important anymore.