⬆️ upgrade templates

[zbeyens]

Description

See changesets.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4831be0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
plate	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 2, 2023 8:52am

[zbeyens]

@shahriar-shojib We have a single type error in the playground template:

Not sure why but it's only for the caption and deserializeMd plugins.

Could you take a look? Will tip $50 for that one 🙂

[shahriar-shojib]

I looked into this one, and the two plugins that are not working are createCaptionPlugin and createDeserializeMdPlugin.

I have tested the same thing on www project and did not face this issue.

Anyhow, the issue is createPlugins expects PlatePlugin<AnyObject, Value, PlateEditor<Value>> and PlatePlugin<CaptionPlugin, Value, PlateEditor<Value>> was provided, however if this was the case this should occur in all other plugins.

I also noticed that each bundle is emitting its own types which should be imported from @plate/common.

Since I am not facing this issue on www leads me to believe that there are some inconsistency on the published packages, I will have to investigate further into this.

[shahriar-shojib]

Hello,
Hopefully creating a release from this branch will fix the issue

https://github.com/udecode/plate/tree/fix/tsup-dts-output

this does not bundle node_modules dts into the package's d.ts which should not only reduce the package size but also improve tsserver and tsc performance on the user's end and ensures all packages are referencing to a single type at a time instead of having them declared on their own package.

[zbeyens]

Also, Lodash issue is still here: https://bundlephobia.com/package/@udecode/[email protected]
With rollup, it was handled by

plate/config/rollup.config.cjs

Lines 110 to 118 in 7be7728

	[
	'import',
	{
	libraryName: 'lodash',
	libraryDirectory: '',
	camel2DashComponentName: false,
	},
	'lodash',
	],

Any idea?

[shahriar-shojib]

Also, Lodash issue is still here: https://bundlephobia.com/package/@udecode/[email protected] With rollup, it was handled by

plate/config/rollup.config.cjs

Lines 110 to 118 in 7be7728

	[
	'import',
	{
	libraryName: 'lodash',
	libraryDirectory: '',
	camel2DashComponentName: false,
	},
	'lodash',
	],

Any idea?

I am checking now

[shahriar-shojib]

I could not find a possible reason why only these two plugins fail typechecking, it seems a lot of types are still bundled into d.ts which because of implicit return types and those types being re-exported from "@plate/common" .

[shahriar-shojib]

type PluginCreatorFn<Options extends PluginOptions = PluginOptions> = <
  V extends Value = Value,
  E extends PlateEditor<V> = PlateEditor<V>,
>(
  override?: Partial<PlatePlugin<NoInfer<Options>, V, E>>,
  overrideByKey?: OverrideByKey<V, E>
) => PlatePlugin;

/**
 * Enables support for caption.
 */
export const createCaptionPlugin: PluginCreatorFn<CaptionPlugin> =
  createPluginFactory<CaptionPlugin>({
    key: KEY_CAPTION,
    withOverrides: withCaption,
    handlers: {
      onKeyDown: onKeyDownCaption,
    },
    options: {
      pluginKeys: [],
    },
  }) as any satisfies PluginCreatorFn<CaptionPlugin>;

is this acceptable as a temporary workaround?

[shahriar-shojib]

Or createPlugin's type can be relaxed

[shahriar-shojib]

or moving createPluginFactory and createPlugins functionality could be moved to @plate/common could fix the issue, I am not 100% sure

[zbeyens]

type PluginCreatorFn<Options extends PluginOptions = PluginOptions> = <
  V extends Value = Value,
  E extends PlateEditor<V> = PlateEditor<V>,
>(
  override?: Partial<PlatePlugin<NoInfer<Options>, V, E>>,
  overrideByKey?: OverrideByKey<V, E>
) => PlatePlugin;

/**
 * Enables support for caption.
 */
export const createCaptionPlugin: PluginCreatorFn<CaptionPlugin> =
  createPluginFactory<CaptionPlugin>({
    key: KEY_CAPTION,
    withOverrides: withCaption,
    handlers: {
      onKeyDown: onKeyDownCaption,
    },
    options: {
      pluginKeys: [],
    },
  }) as any satisfies PluginCreatorFn<CaptionPlugin>;

is this acceptable as a temporary workaround?

Not really, too much overhead, we need to keep type inference. I think the issue appeared because of the interface to type change for AnyObject, not sure.

Type
Partial<PlatePlugin<CaptionPlugin, Value, PlateEditor<Value>>>
is not assignable to type
void | Partial<PlatePlugin<AnyObject, Value, PlateEditor<Value>>>

so the void | is the issue.

createPlugins should return PlatePlugin<AnyObject,...>[] but

[shahriar-shojib]

I will investigate this further, I am surprised that it's not happening in www though.

[zbeyens]

www uses the local build while the templates are using the published version

[zbeyens]

Note that intellisense is extremely slow (and heavy CPU usage) specifically inside createPlugins (I don't think it was the case before)

2023-10-01.at.23.50.04.mp4

If you have a proposal to soften createPlugins type, let me know. Inference is probably messing up here.

[shahriar-shojib]

I will create a private registry and test out the released packages to solve the issue.
As for the tsserver being slow on createPlugins function, I think it's due to the packages bundling d.ts and each having their own types rather than importing.

[zbeyens]

So I've tried to create a minimal reproduction of the tsserver issue. Any array that contains any create*Plugin (created by createPluginFactory) is raising the issue. So PlatePlugin and createPlugins are fine.

I'll do a test release for the other issues in the meantime.

[zbeyens]

Another regression we have is #2661, more context in evanw/esbuild#622 (comment)

I'll add .js to prismjs imports, didn't find an automatic way to do it