Changing build config for better bundlers support

[WilcoSp]

This PR relates to https://github.com/formkit/tempo/issues/37

This PR is to help bundlers like Vite to bundle Tempo without having everything included into 1 big bundle or even into the main index.js file. More information is available here.

The tsup config build will change from:

• Create a bundled index.mjs & index.cjs

to:

• Create an unblunled esm build where index.mjs is only used to export everything
• Create a bundled index.cjs (like before)
• Create an esm bundle as bundle.mjs (for browsers/cdn)

I've also added to package.json the following:

• A browser & unpkg export that point to bundle.mjs
• installing esbuild-plugin-file-path-extensions to have the unbundled esm build with all imports having the ".mjs" extension, without this plugin no imports will have the needed file extension

If there are any thoughts or feedback let me know below

[vercel[bot]]

@WilcoSp is attempting to deploy a commit to the Formkit Team on Vercel.

A member of the Team first needs to authorize it.

[justin-schroeder]

Hey @WilcoSp! thanks for spending time working on Tempo! I really appreciate the effort.

I’ll admit, however, I’m a bit confused about this PR. Most modern npm packages are bundled into a single entry point — tempo is doing not different in this regard. Often packages with a lot of individually exported files do so for legacy CDN support — something I don’t think tempo needs to proffer.

As for the tree shaking in the reproduction examples, as far as I can tell this is due to the dynamic imports to FormatComp, FormatSplit, ParseComp, and ParseSplit which in turn load most of tempo. Vite (rollup) does a static analysis of this and sees they all resolve the same module and it bundles them into a singular chunk to avoid the cost of additional requests. This seems to be be working how it should. If I only import one of these in the project, I only get that one function. In no cases (as far as I can tell) do you get functions that are not used in the project at all (perhaps I am incorrect on this and you can point to where to look?).

Tempo, as far as I can tell tree shakes just fine, you can play around with it in the rollup repl which is ultimately what vite uses under the hood.

Now, I publish quite a few npm packages, so I’m well aware of how incredibly complicated and convoluted bundling and packaging can be —  in otherwords I could be wrong here. In that spirit, perhaps you could educate me with some documentation or further reading as to why we should ship many modules instead of one — what are the and pros/cons — what modern packages do this — and why — etc. Thanks again!

[WilcoSp]

Hey @justin-schroeder this PR isn't about treeshaking itself, that's something Tempo does very well but it's about Tempo isn't able to be split into chunks by bundlers because it's being exported as 1 module file.

Because tempo can't be made into separate chunks based on usage across multiple ts/js files, it can happen that everything from Tempo gets put into 1 bigger chunk (without build from example) or into the entry index.js (with build from example) of a project that is build.

With this PR I try to solve chunking by exporting Tempo into multiple modules so that bundlers like Vite/Rollup can bundle a project more efficient and with less overhead, this helps in big projects which may use format/parse in a very deep route (simulated in example by using defineAsyncComponent) while using startYear or any other smaller function closer to the main index.js

Here are also bundle visualizers from the example to demonstrate better with what I mean.

• with build, startYear close to index.js
• without build, doesn't have startYear

The FormatComp & ParseComp components use Tempo from NPM, while FormatSplit& ParseSplit use the forked version as @wilcosp/formkit-tempo with the build step from this PR, The with build also includes the yearStart function from both NPM & PR fork and gets bundled into index-CgZb_po2.js (the main build index.js)

In short for multiple exported modules

Pros:

• less overhead
• more efficient bundling with Vite/Rollup because Tempo can be split into multiple chunks

Cons:

• Yet another npm package to keep an eye on every time updating dependencies, sadly didn't find any tsup/esbuild option to make it possible without
• not practical for commonjs & browser/cdn but for those I've created separate build steps to make index.cjs & bundle.mjs

other libraries that export multiple modules and still well maintained

• date-fns (in their words: It works well with modern module bundlers such as webpack, Browserify, and Rollup and also supports tree-shaking.)
• Angular core & other google maintained Angular libraries
• Vuetify/Quasar/PrimeVue
• next
• nuxt
• @apollo/client
• @vue/apollo-composable

Hopefully this gives you more information and if there still questions or need help, let me know as this was also very new to me and if you want I can join the Formkit Discord.

[justin-schroeder]

Thank you for the helpful explanation. I think I can see the utility in this for sure. I’ll merge it into a future release branch and play around with it a bit. Thanks!

[WilcoSp]

Your welcome Justin and I'm glad I was able to make Tempo better.

I'll also contribute more to Tempo for things I like to be added.