Update build configuration

[sebastiandedeyne]

This is a draft PR and currently only targets the main Inertia package for the sake of discussion. I'll update the other build configurations after we've drawn our conclusions.

Triggered by the discussion at #447 I decided to look into the current build situation and see if we can do better. It's been over a year since this was all set up, and with JavaScript tools moving forward it doesn't hurt to take a step back every now and then.

Tldr; we should support ESM in addition to CJS and UMD.

---

My dream situation would be a single "build": "microbundle" script without any additional configuration, but alas I don't think that's a fit for Inertia.

Current status

We currently ship two builds:

• CJS (CommonJS): supported in bundlers like Webpack, Vite, or Rollup
• UMD: supported in in browsers

UMD builds use the --external none setting. This ensures that the package dependencies (axios, deepmerge & qs) are bundled with the build. When someone loads the file straight in their browser, they don't need to add additional dependencies. The CommonJS build doesn't need this, because bundlers take care of this at compile time.

Supporting ESM

Fast forward since this was first set up, and there's new relevant module format on the block: ESM. ESM is the one-standard-to-rule-them-all system that tools like Webpack and Vite are using by default now. The benefit of ESM is that it should work everywhere (or will at some point) and is tree-shakable. Build tools are able to detect unused code and slim down the module.

Side note on Vite: Vite uses ESM as the default format. Anything non-ESM needs to be transformed before it can run. The more dependencies ship ESM, the less work Vite has.

The --external none thing is still an issue though: we don't want to ship dependencies to bundlers, but we want them readily available for browsers. Microbundle has a new-ish "modern" build mode which generates an ESM bundle specifically for browsers. Similar to UMD, we'd add the --external none flag for the browser build.

That brings us to this updated configuration:

  {
    "scripts": {
-     "build": "npm run build:cjs && npm run build:umd",    
+     "build": "npm run build:bundler && npm run build:browser",
-     "build:cjs": "microbundle --format cjs",
+     "build:bundler": "microbundle --format es,cjs",
-     "build:umd": "microbundle --format umd --name Inertia --external none",
+     "build:browser": "microbundle --format modern,umd --name Inertia --external none"
    }
  }

(I don't like the build:bundler script name but haven't thought of anything better yet)

Do browser builds make sense?

Final question: do browser builds actually make sense for Inertia? While technically possible, I haven't come across anyone using Inertia without a bundler. Is it worth supporting browser builds?

Resources

• Difference between the formats
• Related Microbundle discussion
• How Microbundle decides which dependencies to bundle

[claudiodekker]

do browser builds actually make sense for Inertia?

To me it does, at least for local development. In prod. I'd definitely use a bundled/non-browser build, but if they're hot-swappable that totally shouldn't make any difference.

[sebastiandedeyne]

Then we'll definitely keep those!

[garlandcrow]

@sebastiandedeyne I was playing around for the past few days trying to get Vite + InertiaJS + Svelte to work. Initial attempt was to do the same thing as a few people had done to get Vue working, the critical Vite config change needed for Vue is

optimizeDeps: {
    include: [
      "@inertiajs/inertia",
      "@inertiajs/inertia-vue3",
    ],

But when switching everything to the Svelte equivalents, this gets things compiling but using shared props (and probably other things) do not work:

import { page } from "@inertiajs/inertia-svelte";
console.log($page)

This logs an empty object and doesn't observe any changes (@robert on the discord confirmed that there seems to be 2 stores created and thats why there is no update). So I tried out using the config file in this PR and removing the optimizeDeps key and found that solves the issue. So for InertiaJS + Svelte to work in Vite, this config change with the ESM build is required.

So hopefully we can get this one merged in the next release 😄 Let me know if any questions.

[claudiodekker]

@reinink thoughts? Personally, I'd love to see this move forward before eventually tagging 1.0.

[reinink]

Hey! Thanks so much for your interest in Inertia.js and for submitting this contribution.

In an attempt to get on top of the issues and pull requests on this project I am going through all the older issues and PRs and closing them, as there's a decent chance that they have since been resolved or are simply not relevant any longer. My hope is that with a "clean slate" me and the other project maintainers will be able to better keep on top of issues and PRs moving forward.

Of course there's a chance that this PR is still relevant, and if that's the case feel free to re-submit it. If it's a new feature and not a bug fix maybe respond here first to make sure that it's something we want to include in the library.

Really not trying to be dismissive here, I just need to find a way to get this project back into a state that I am able to maintain it. Hope that makes sense! ❤️

[thecrypticace]

FYI, v1.0 shipped with ESM and CJS builds when we swapped out microbundle for esbuild.