Field type build tool

[emmatown]

This is a continuation of things discussed in #927.

The tool is essentially a fork of preconstruct, there's a bunch of stuff I'm going to rip out though that this tool won't need so I wouldn't recommend reviewing the implementation of this right now.

Something that I would like to hear thoughts on is the API, I've converted @keystone-alpha/fields-wysiwyg-tinymce and it works. Below is essentially the most important part of the API, to import views, you call importView which you import from @keystone-alpha/build-field-types
https://github.com/keystonejs/keystone-5/blob/7eddd38ca4de25aca4f6754e99670e3ccb1c86ce/packages/fields-wysiwyg-tinymce/src/index.js#L1-L20

TODO

• figure out how dev stuff should work inside and outside the monorepo
• build ESM bundles and make chunks resolve to directories that are automatically created in the dist folder with the correct package.json files and bundles
• probably a bunch of other stuff
• get all the tests working

[JedWatson]

This is really interesting, if it works 😍

[JedWatson]

I really like what this does to the Keystone field package structure.

Can you share what it would look like (in terms of file structure, screenshot or comment here would do) for the main fields package?

Also, do you think this changes anything for other views (e.g. for custom pages in the Admin UI)? There aren't any chances to the fields-loader, which we've talked about extending, just double-checking that's a separate thing.

Thoughts unrelated to the API:

• The fields introduces flow for server-side code for the first time. I'm ... mixed on that? not sure what it's going to do to the dev loop. Probably fine since build-field-types is a CLI package, so the main Keystone experience isn't affected in any way 🤷‍♂️
• The wysiwyg field's index.js also moves behind the build step... which I think is OK since that's now consistent with other packages like utils that preconstruct builds for universal use anyway. But it seems a bit weird, since there's a hard boundary between the server and client parts of each field. Is that change necessary?

[emmatown]

Can you share what it would look like (in terms of file structure, screenshot or comment here would do) for the main fields package?

Also, do you think this changes anything for other views (e.g. for custom pages in the Admin UI)? There aren't any chances to the fields-loader, which we've talked about extending, just double-checking that's a separate thing.

It shouldn't change anything about that.

The wysiwyg field's index.js also moves behind the build step... which I think is OK since that's now consistent with other packages like utils that preconstruct builds for universal use anyway. But it seems a bit weird, since there's a hard boundary between the server and client parts of each field. Is that change necessary?

Having the server side parts of field types behind a build step is what enables importView so, yes, it's necessary.

👇 is an explanation of how importView will work which might answer any other questions you might have.

We have a file like this,

import { importView } from '@keystone-alpha/build-field-types';

export let Wysiwyg = {
  ...otherStuff
  views: {
    ...otherViewsStuff
    Field: importView('./views/Field'),
  },
};

It goes through a babel plugin which turns it into this

export let Wysiwyg = {
  ...otherStuff
  views: {
    ...otherViewsStuff
    Field: ___KS_BUILD_SYSTEM_INTERNAL___importView(import('./views/Field')),
  },
};

Rollup does its thing and we have this for CommonJS builds. (and a different thing for ESM but I'm going to ignore that for this explanation) It's going to be written to the dist folder.

exports.Wysiwyg = {
  ...otherStuff
  views: {
    ...otherViewsStuff
    Field: ___KS_BUILD_SYSTEM_INTERNAL___importView(Promise.resolve(require('./chunk-hash'))),
  },
};

We then transform it with another babel plugin into this

const _join = require('path').join

exports.Wysiwyg = {
  ...otherStuff
  views: {
    ...otherViewsStuff
    Field: _join(__dirname, './chunk-hash'),
  },
};

And rollup will write the ESM and CJS versions of that chunk to dist/chunk-hash/not-sure-about-the-filename-yet.cjs.js and dist/chunk-hash/not-sure-about-the-filename-yet.esm.js and build-field-types will write a package.json with main and module fields to dist/chunk-hash/package.json

[JedWatson]

❤️ it @mitchellhamilton

[emmatown]

I want to call out this change in case anyone has any concerns. From #214 it seems like we're okay with not supporting IE 11.

The reason I did this isn't really for smaller bundles but that's a nice benefit, I did this is because there's a bug in Babel which means Babel compiled classes can't extend native classes. (babel/babel#9367)

[timleslie]

To the future! 🚀

[jesstelford]

🎉

[jesstelford]

👍

[jesstelford]

Suggested change

// We perform the requires here to avoid circular dependencies