Skip to content

Latest commit

 

History

History
107 lines (93 loc) · 5.44 KB

Plan.md

File metadata and controls

107 lines (93 loc) · 5.44 KB
Raw

Plan

Auto-abstract css utilities

  • Auto-abstract colors

    • Detect when css uses properties like theme colors
    • Match the abstracted color out of the css property
    • Detect all color-parameterizable properties (maybe detect everything with color suffixes?)
      • List all colors for a tailwind config
      • Detect suffixes
    • Fix exposes with new config
    • Detect transparent colors (e.g. blue-500/95) (use theme.opacity)
    • withOpacity : Theme.Opacity -> Theme.Color -> Theme.Color helper
    • Look at counterexamples & fix them
      • Detect color values in 'suspected to be parameterizable' definitions
      • Detect better where/when to replace values with abstract color var
        • Handle cases of computed opacity values (opacity replaced with 0)
        • Handle cases of color appearing mid-value (e.g. viaWithColor)
      • Handle colors without opacity variables correctly (e.g. caretWithColor)
      • Use declaration.opacityVariableName
      • Refactor: Remove isParameterized parameter
      • Look through TODOs in the code
    • Generate & use opacity variants: Make opacity_50 etc. use Theme.Opacity instead
    • Handle naming option in CLI for camel case in isParameterizable in parser code Turns out that has always been disabled. Removed the dead code path
    • Use a non-primitive elm type for colors (instead of String)
    • Get numbers on the size difference (88320 exposed values vs. 3812)
    • Figure out naming. (e.g. parameterized border vs. border property). Have a WithColor suffix
    • Think about custom documentation support.
      • Just ended up adding a separate function
    • Think about whether we want something like type Color opacity and Color () or Color Never. The idea being that some functions like viaWithColor or fromWithColor will always overwrite the opacity, thus it doesn't make sense to pass opacity in. Not worth it! Only 2 places in Utilities that override withOpacity.
    • Think about "Refactor Internal functions like toProperty in Theme" (see below)
    • Publish
    • (optionally: Look at refactoring? E.g. detect & deduplicate outside of code-generators/ files)
    • Release new default-tailwind-modules with Tailwind v3
    • Support new API format in https://html-to-elm.com/

  • Detect when css uses the same spacing values over and over

  • Break Tailwind.Theme into two modules: Tailwind.Internal and Tailwind.Theme. Tailwind.Theme then contains symlinks for type alias Color = Tailwind.Internal.Color and opacity, as well as all color and opacity definitions. Tailwind.Internal contains the actual type definitions and the toProperty* functions. Then, in elm-default-tailwind-modules, we can export Tailwind.Theme, but keep Tailwind.Internal private.

General

  • Use esbuild (much faster builds, great watch mode for yarn linked development)
  • Do end-to-end snapshot testing
  • Generate breakpoint utilities by analysing tailwind config
    • Simple breakpoint module generation
    • Fix tests
    • Parse all kinds of breakpoints. Test them.
  • Figure out good darkmode support when the darkmode is configured to classes (https://tailwindcss.com/docs/dark-mode#toggling-dark-mode-manually)
  • Improve performance. Main cost centre seems to be in src/helpers.ts#toElmName.

Done

  • Remove cli option for looking up postcss

    • Write more extensive docs for using asPostcssPlugin in readme

  • Simplify call structure in code-generation (get rid of options)

  • Extract elm code generation elements

  • Use 'property' instead of typed elm-css

  • Figure out how to handle custom css:

    • This is the big one.
    • Either: Find component css selectors (group by .prose, e.g.)
    • Or: Run differently for @tailwind utilities and @tailwind components
    • E.g. Handle tailwindcss' typography plugin: do '.prose' correctly.

  • Rename the library

  • Recognize keyframe animation stuff

    • Refactor how the postcss walk works. Don't walkRules, but .each, detect the kind of child (media query/keyframe/rule) and handle accordingly.

    • Detect css properties that end in "animation" or "animation-name".

      Have a list of defined keyframe animations ready.
Replace any occuring keyframe animation name in those css properties with an empty string.
Add the css animation via the elm-css animationName mechanism.

  • Fix CI

  • Fix "font-size: [object Object]"

    • This is a bug of tailwind 2.0 with the tailwindui plugin. Luckly this plugin is obsolete
    • Remove tailwindui

  • Add a test that ensures generated modules are formatted

  • Add a command line interface

    • Add a cli.ts module
    • Rollup code for that module
    • Add an entry in package.json for "bin"

  • Expand possible integration use cases

    • Allow custom postcss
    • Export as postcss plugin

  • Write README/docs

    • Add jsdoc for index.ts

  • Fix selectors like .aspect-w-1, .aspect-w-2 or .ordinal, .slashed-zero, etc. which are just shortcuts for setting this for all classes individually.

  • Clear docs/ and dist/ before builds

Refactoring

  • Use typescript
  • Use typescript for tests
  • Use rollup to compile to udm/commonjs/esm
  • Drop jest, use ava
  • Enable more strict typescript

small things

  • Remove double-iteration over rules in parser