Switch from rollup to vite, from commonjs to ecmascript modules

[flevi29]

Pull Request

Related issue

Fixes #1626
Waiting on #1739

What does this PR do?

• switches bundler from rollup to vite, which internally uses rollup, but makes things a lot shorter and simpler
  • removes the need for separate vitest.config.js
  • removes the need for scripts/file-size.js, packages kleur, pretty-bytes, brotli-size, gzip-size, as it prints sizes by default
  • removes the need for all of the rollup plugins and dependencies (@rollup/plugin-terser, @babel/core, @babel/preset-env, @rollup/plugin-babel, @rollup/plugin-commonjs, @rollup/plugin-json, @rollup/plugin-node-resolve, rollup-plugin-typescript2)
  • removes the need for shx package, and cleanup script, as it clears dist itself
• switches from CJS to ESM ("type": "module")
  • every .js project file now needs to be written in ESM syntax, the web standard syntax
  • TypeScript files were already written in ESM syntax, so this just makes things more consistent
• updates TypeScript and makes some changes to tsconfig.json according to https://www.typescriptlang.org/docs/handbook/modules/guides/choosing-compiler-options.html#im-writing-a-library
  • is now used to transpile ESM version of this package
  • most importantly sets module to node16 and verbatimModuleSyntax to true, this requires changes to all TypeScript files so they may be compatible with the web standard ESM
    • all imported files now require a .js extension
    • there is no more support for index directory imports, as that is only a Node.js thing, the web doesn't support it
    • when importing types, we need to explicitly specify that we're doing so with the type keyword

Warning

• DEPRECATE default export Remove default export #1789
• DEPRECATION: UMD bundle will no longer extend window with the exports in the future, instead it will only extend it with property meilisearch which contains the exports Do not extend window with all of the exports in UMD bundle, rather just a property of window #1806

Old

<script>
  const client = new MeiliSearch(/* ... */);
</script>

New

<script>
  const client = new meilisearch.MeiliSearch(/* ... */);
</script>

PR checklist

Please check if your PR fulfills the following requirements:

• Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
• Have you read the contributing guidelines?
• Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.21%. Comparing base (7032370) to head (12c0df8).
Report is 38 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1740   +/-   ##
=======================================
  Coverage   98.20%   98.21%           
=======================================
  Files          18       17    -1     
  Lines        1562     1565    +3     
  Branches      333      333           
=======================================
+ Hits         1534     1537    +3     
  Misses         28       28           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[flevi29]

Hey @brunoocasali, it's been a while. Please, can you take a look at this PR? It would unblock me from contributing even more, for instance using vite to greatly improve the live demo test.

[Strift]

I support this change too 👍 However, I would recommend making this non-breaking for users.

For the exports: I would add information in the documentation to explain that default export is deprecated, will be removed one day, and named export should be preferred.

For the UMD bundle: is there a way to approach it in the same way? Via documentation, and roll out the breaking change in the future.

[flevi29]

Thanks for the feedback, I'll try to do just that.

[Strift]

Hello @flevi29, thanks so much for this PR 🙌

Most things look good after testing things on my end. I have some questions before moving forward with reviewing the rollup/vite configuration.

Filename imports: Why are you importing from "{filename}.js" files even when the extension is ".ts"? Wouldn't it be clearer to import for "filename.ts" instead?

Type file: Is there any reason why you renamed types/index.ts to types/types.ts? I think the former file name is more conventional.

[Strift]

Thanks for figuring that out.

Can you please add two comment?

• One comment explaining what this code does, e.g. enable the window.Meilisearch syntax
• One TODO comment so we know where to look to remove this in the future

[flevi29]

Did it!

[flevi29]

Filename imports: Why are you importing from "{filename}.js" files even when the extension is ".ts"? Wouldn't it be clearer to import for "filename.ts" instead?

Because TypeScript doesn't rewrite extensions: https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution-for-bundlers-typescript-runtimes-and-nodejs-loaders

Type file: Is there any reason why you renamed types/index.ts to types/types.ts? I think the former file name is more conventional.

There was an index file for a single types.ts file, which didn't make a whole lot of sense. I deleted the directory instead now, which is what I should've done.

[Strift]

Filename imports: Why are you importing from "{filename}.js" files even when the extension is ".ts"? Wouldn't it be clearer to import for "filename.ts" instead?

Because TypeScript doesn't rewrite extensions: https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution-for-bundlers-typescript-runtimes-and-nodejs-loaders

This seems relevant when compiling through TypeScript only. But in our case, we are bundling our code with Vite.

The docs you shared mention this scenario:

But what if there is no output JS file? What if you’re in one of these situations:

• You’re bundling this code, the bundler is configured to transpile TypeScript files in-memory, and it will eventually consume and erase all the imports you’ve written to produce a bundle.
• You’re running this code directly in a TypeScript runtime like Deno or Bun.
• You’re using ts-node, tsx, or another transpiling loader for Node.

In these cases, you can turn on noEmit (or emitDeclarationOnly) and allowImportingTsExtensionsto disable emitting unsafe JavaScript files and silence the error on .ts-extensioned imports.

---

The README update is sufficient for now, I will update it in a follow-up PR.

[Strift]

Can you remove the comment and only use the recommended way?

[flevi29]

Filename imports: Why are you importing from "{filename}.js" files even when the extension is ".ts"? Wouldn't it be clearer to import for "filename.ts" instead?

Because TypeScript doesn't rewrite extensions: https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution-for-bundlers-typescript-runtimes-and-nodejs-loaders

This seems relevant when compiling through TypeScript only. But in our case, we are bundling our code with Vite.

The docs you shared mention this scenario:

But what if there is no output JS file? What if you’re in one of these situations:

• You’re bundling this code, the bundler is configured to transpile TypeScript files in-memory, and it will eventually consume and erase all the imports you’ve written to produce a bundle.
• You’re running this code directly in a TypeScript runtime like Deno or Bun.
• You’re using ts-node, tsx, or another transpiling loader for Node.

In these cases, you can turn on noEmit (or emitDeclarationOnly) and allowImportingTsExtensionsto disable emitting unsafe JavaScript files and silence the error on .ts-extensioned imports.

But we aren't bundling the ESM version, that's handled & transformed by TypeScript. The whole point of ESM is that it finally has a module system for the web, so no bundling is required. CJS also has a module system (incompatible with the web) (require), but it's not statically analyzable like ESM import is. And TypeScript already does a lot of work on analyzing the code, which it uses to also transform the code, so I thought it'd be the best to use it to output the ESM version.

[Strift]

But we aren't bundling the ESM version, that's handled & transformed by TypeScript. The whole point of ESM is that it finally has a module system for the web, so no bundling is required. CJS also has a module system (incompatible with the web) (require), but it's not statically analyzable like ESM import is. And TypeScript already does a lot of work on analyzing the code, which it uses to also transform the code, so I thought it'd be the best to use it to output the ESM version.

Alright, that makes sense! I eventually reached that conclusion as I looked into the build process, but forgot to update this part of my review.

Thanks for the feedback and prompt follow-up.

Let's get this merged 🔥

[Strift]

bors merge

[meili-bors]

Build succeeded:

• integration-tests (Node.js 18)
• integration-tests (Node.js 20)
• style-check
• types-check