roots / palette-webpack-plugin Goto Github PK

Tailwinds supports custom color palettes: https://tailwindcss.com/docs/customizing-colors#custom-colors

At the moment, this plugin has very weird behaviour with this kind of configuration as it's looking for numbered shades as per a default configuration.

I've quickly patched this on a fork so we can continue working with it (lgladdy@74fb5c5) but I'm not sure of the repercussions of removing isNaN, so didn't want to submit it as a PR without discussion.

If you follow the custom configuration example on tailwind's docs, you'll end up with duplicate key names because of the isNaN check, and the majority of your colours will be excluded. Removing this isNaN check (and enabling shades) forces the correct generation with my patch, but this is probably not the best way of moving forward.

Potentially, the best solution would be to check for NaN keys which still have a value, and auto-enable shades in that case, and remove the isNaN check?

I'm happy to write this code and submit a PR, but would value some input from the core dev(s) on if this seems sensible?

Terms

• I have read the guidelines for Contributing to Roots Projects
• This request is not a duplicate of an existing issue
• This is not a personal support request that should be posted on the Roots Discourse community

Summary

A theme theme.json is the new, best-practices standard for defining theme-specific settings (primarily used for the Gutenberg editor), including the palette.

Motivation

Why are we doing this?

The theme.json can (and should be) used for declaring the theme palette.

What use cases does it support?

All new themes (mainly tailored to Gutenberg) that declare the theme palette in theme.json.

What is the expected outcome?

Less config duplication.
The usage of a standardized place for the theme palette.

Potential conflicts / foreseeable issues

When the option for adding/merging in more palettes besides from the theme.json is kept,
there should be no conflicts or issues.

Additional Context

No response

tailwind: {
  config: './tailwind.config.js',
  shades: {
    '100': 'Light',
    '500': '',
    '800': 'Dark',
  },
  path: 'colors',
},

would result in:

Light Gray
Gray
Dark Gray

instead of:

Gray (100)
Gray (500)
Gray (800)

• I've read the guidelines for Contributing to Roots Projects
• This request isn't a duplicate of an existing request
• This is not a personal support request that should be posted on the Roots Discourse community

Summary

Currently color labels can't be translated using the WordPress i18n functions (like __).
Also it may make sense to be able to define a different label/slug.

Motivation

Multilingual backend language should support translation of Gutenberg colors.
The slug stays the same, but the labels are different.

tailwind: {
  shades: [300, 400, 500],
}

See: https://github.com/roots/palette-webpack-plugin/blob/master/src/index.js#L159-L164

• I've read the guidelines for Contributing to Roots Projects
• This request isn't a duplicate of an existing request
• This is not a personal support request that should be posted on the Roots Discourse community

Summary

Add the ability to fill the editor-gradient-presets in similar way as the color palette via this plugin.

Motivation

Having to manage your brand colors in once place instead of 2 is great! I use it every single day in my new gutenberg era way of work. As there is now gradient support in a very easy way in custom blocks I would love to see this supported by the pallete-webpack-plugin.

Additional context

Gradient presets also have three parts to be filled.

add_theme_support(
      'editor-gradient-presets',
      [
         [
            'name'     => Red to transparent,
            'gradient' => 'linear-gradient(180deg,#263e45 0,rgba(38,62,69,.8) 10%,rgba(38,62,69,0)',
            'slug'     => 'red-to-transparent',
         ],
      ]
   );

So i think the output function almost can be the same but then outputs to a gradients.json? I'd love to hear what you think.

• I've read the guidelines for Contributing to Roots Projects
• This request isn't a duplicate of an existing issue
• I've read the docs and followed them (if applicable)
• This is not a personal support request that should be posted on the Roots Discourse community

Description

Hi, I am using this plugin for my webpack workflow. It seems that this plugin still uses the emit hook which causes the DeprecationWarning: Compilation.assets will be frozen in future, all modifications are deprecated. BREAKING CHANGE: No more changes should happen to Compilation.assets after sealing the Compilation. warning.

As pointed out in webpack/webpack#11425 something like this should be used to support webpack 4 and 5: webpack/webpack#11425 (comment). In my case this causes an issue with the webpack-manifest-plugin where the files generated by this plugin are not in the manifest.

Another plugin I use runs into the same issue as well and see the comment over there about the hook usage: WordPress/gutenberg#27984

Steps to reproduce

Use this plugin in combination with the latest version of the manifest plugin. See that the manifest plugin doesn't contain the json/php file.

If needed I can make an example repo.

Expected behavior:
The PHP/JSON file(s) also get added to the manifest.

Actual behavior:
File(s) doesn't get added.

Reproduces how often: 100%

Versions

webpack: 5.15
palette-webpack-plugin:1.0.2
webpack-manifest-plugin: 3.0

Additional information

Any additional information, configuration or data that might be necessary to reproduce the issue.