flyonui: the manifest says MIT and the readme says part of it is not

Two sentences about licensing that do not agree with the manifest

The overview section contains a pair of statements about terms, and they divide the package in half.

The first says the project's own original code is under a permissive open-source licence. The second says bundled third-party components are governed by their respective licences, as set out on a licence page and in the files themselves.

So the answer to what licence this package is under is: the original code has one, and something inside it does not. The readme does not name that something in this section, deferring to a page and to per-file notices instead.

Now compare the package manifest, which carries a single licence field with one value. That is the field every tool reads. A licence inventory tool, a policy scanner, a notice generator, a corporate compliance check: all of them read that one string and conclude the entire package is permissive.

And the platform's own view of the repository records nothing at all, so a reader who asks the hosting service what the terms are gets no answer either.

This is not a sleight of hand. A single scalar field genuinely cannot express a package that mixes your own permissive code with bundled components under other terms, which is why the readme adds prose. But the prose is where a human looks and the field is where a machine looks, and only one of them is careful.

The differentiator is credited to two other projects in the same paragraph

The overview has a short list introduced by the phrase under the hood, it uses the strengths of, followed by three links.

The first is the CSS framework the whole thing sits on. The second adds component semantic class names to that framework so you can build faster and maintain more easily. The third supplies headless, fully unstyled JavaScript plugins for accessible interfaces, with animations and transitions.

Read that against the two sections that follow. The first says Tailwind alone gives you cluttered markup with many utility classes, and that a component library brings semantic class names for readability. The second says neither the framework nor the semantic-class library provides interactive components like accordions, overlays, or dropdowns, and that this is where the project shines.

So both halves of the value proposition are, in the same document, attributed to the other two projects. The project's own contribution is the assembly: the selection, the examples, the configuration surface, and the fact that the two sit together.

That is worth saying plainly rather than treating as a weakness. Most libraries in this space obscure their inputs. This one names them in the first screen of the document and points at each project's own site.

The practical consequence is in the upgrade path. You are taking a dependency on the framework, on the semantic-class library, and on the plugin library, and this project is the one that has to keep all three aligned. The search terms for this repository are dominated by exactly that question, with repeated comparisons against the semantic-class library and against another component approach.

The headline number counts examples and the readme calls it hundreds

The first item on the features list is a number: eight hundred or more free component examples, described as meeting accessibility criteria.

The count is of examples, and the wording is careful. It says examples, and the same item's supporting sentence says hundreds of component examples for your needs. So the document contains both the large number and a smaller one describing the same thing.

Meanwhile the surrounding language is about components rather than examples. The project describes itself as a component library, the overview describes it as a component library, and the badge at the top describes it as a component library. A reader scanning the feature list sees a number attached to the word examples and a description that says components.

That gap is the kind that matters for a library whose pitch is volume. If you are choosing between this and an alternative on the grounds that one has more of something, the number you are comparing is the number of documented snippets rather than the number of distinct things you can put in your interface.

The exclusion in the published tarball sharpens the point. The manifest's file list includes a components directory and then, immediately after it, a negated pattern excluding a metadata file from every component subdirectory. So the tarball ships the styles for each component and omits the structured description of each component.

Fifteen frameworks are fifteen links to a documentation site

The framework guides section is a grid. Five columns, several rows, one framework name per cell, and under each name a link to a page on the project's documentation site.

Counting the visible cells gives fifteen: a plain HTML page and then fourteen named frameworks and templating languages, spanning component frameworks on both sides of the island, a meta-framework and its Vue equivalent, two more meta-frameworks, a Python framework, two Python micro-frameworks, a PHP framework, and a static site generator.

What the grid is not is fifteen builds. The published tarball's file list is framework-agnostic: a base directory, a colours directory, a components directory, a theme directory, a utilities directory, a handful of named plugin function files, an imports file, an entry module, and three stylesheets.

The manifest's two entry points make the same point. The main field is a JavaScript module; the browser field is a stylesheet.

So a framework guide is a page showing you how to wire the same stylesheet into that framework's template syntax. That is genuinely useful work, fifteen times over, and it is documentation rather than fifteen compatibility surfaces. The features list calls the coverage universal, which is a fair description of a CSS bundle, and the compatibility question that actually matters is the plugin layer, which is where the real behaviour lives.

The keyword list includes a different product's name

The manifest's keyword list runs to about fifty entries, and reading it is a lesson in how discoverability is done.

Most of the entries are the framework's own name with a variety of suffixes: the library name alone, shortened forms of it, and then the name followed by tailwind, react, vue, next, nuxt, svelte, astro, laravel, rails, plugin, components, sections, library, and css.

Then there is one that is not. An entry reads as a different, well-known component library's name followed by tailwind. It is the only entry in the list that names a competitor.

There is also repetition within the list. Plain words for css, ui, component, and framework each appear twice, and both the singular and plural forms of component appear alongside each other.

None of this harms anyone who installs the package. All of it is aimed at the moment someone types a search term, and a package index's search is a text match over exactly these fields.

It is worth reading as a description of how a small library competes for a generic name rather than as a design decision. The people who run the registry see fifty keywords, one of which is a rival's brand.

Free forever is on the feature list

The features list has six items, and five of them are technical.

Beautiful and semantic styling. Interactive and dynamic features. Efficiency and productivity. Maintainable and scalable. Responsive with right-to-left language support.

The sixth is that it is free forever, open source, and built for the community.

That is a business-model claim sitting in a list of engineering capabilities, and it is the only one of the six that is not a thing the library does. The first five describe what you get. The sixth describes what the maintainer has decided about the price.

It reads oddly next to the rest because a feature list is normally evidence rather than reassurance. Nothing else in the document makes a forward-looking promise on the maintainer's behalf, and nothing else in the document can be wrong later.

It is also the item a reader is most likely to remember, which is presumably why it is there.

The one place the document does make a commitment with teeth is elsewhere, in the licensing note, where it carefully separates its own code from the bundled components and points at the file-level notices. That is a harder promise to keep and a more useful one to have.

Two build configurations, and one of the filenames repeats its own extension

The repository root is small and its contents describe a build pipeline rather than a library.

There is a build script, a Webpack configuration in the CommonJS form, and a second Webpack configuration whose name repeats its extension twice, carrying the module-system extension and the CommonJS extension in one filename. It is almost certainly a rename that was applied to the wrong half of the name.

Alongside that there is a type declaration configuration, two TypeScript configurations, one for the main sources and one named for the module-system build, a generated type declaration file at the root, a global type declaration, a stylesheet of variants, and a pre-commit style configuration.

The two TypeScript configurations are the sensible part. A package that emits both a module-system and a CommonJS build needs to type-check each under the resolution rules of the consumer it is targeting, and two configurations is the honest way to do that. The generated declaration file at the root is consistent with the manifest pointing its main field at a JavaScript file rather than at types.

So the build setup is more thoughtful than the filename suggests. It is just that a file called the same thing twice is the first thing you see in the root listing, and it is the sort of artefact that survives because nobody opens the build directory.

Editorial conclusion

The components are worth using and the examples are the genuinely valuable part, but this is a package with two layers and you should know which one you are taking. Read the licence page before shipping anything, because the manifest's single field does not describe the whole tarball and a scanner will believe the manifest. Be equally clear-eyed about the attribution: the semantic class layer and the interactive plugin layer are other projects' work, which the project states plainly, and that is a point in its favour rather than against it. What that means practically is that your upgrade path has two upstream dependencies you do not control, so pin this package rather than tracking it, and expect breakage to arrive from either side.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. themeselection/flyonui on GitHub