tomhodgins / css-package-manager Goto Github PK

What does it mean to make a 'CSS package' and what information is needed to handle it and all of its information and dependencies?

I wonder if a 'package' is defined by a CSS stylesheet in 100% valid CSS syntax, maybe using a custom at-rule like @--package to wrap a list of declarations similar to the properties defined in a package.json file for an npm module.

When a 'css package' is referenced or consumed, this stylesheet acts as the entrypoint. Inside it, the tooling that works with CSS packages should be able to learn:

• metadata about the package: name, description, author, license, homepage, etc
• which files and folders of CSS to process
• any external dependencies (libraries, frameworks, worklets, plugins, etc)
• any preprocessing instructions for the CSS
• any postprocessing instructions for the CSS (formatting, minification, etc)

Should it indicate something about the output formats or types (CSS, JavaScript, other assets generated during the process).

I've put an example for this idea at /examples/package.css

What do you think is needed for this to work?

Let's brainstorm how we could make this work!

Taken from Discord:

I'm not sure how necessary a dedicated CSS package manager is when we have npm, Sass @use and ES6 import syntax.

The primary focus of npm is JS but you can upload anything to npm.

If you combine this with the new Sass @use syntax (think JS style imports but for CSS) you already have all the dependency tracking you need.

To use the example you gave:
Person one makes a CSS worklet for generating geometric layouts and uploads it to npm.

Person two makes the game board interfaces using person one's npm package. They upload their game boards up to npm.

You are building a game and find Person Two's package. You npm install it (thus keeping track of all dependencies).

You write this in your Sass file:

main {
  display: layout(game-board);
  --shape: triangle;
  --size: 100;
}

And this in your worklet file:

@import "game-board/triangle"

That might be a bit of a bad example since CSS worklets don't require importing any special CSS to make them work.

Or maybe that's the perfect example for explaining why this sort of thing is needed. There is no dependency tracking in the CSS file where you write your dependent CSS.

This was kind of a bit of a rant. Sorry 🙁

My main point is that the stuff that this package aims to achieve is already pretty much possible without it. If you want to go ahead with this, then I would aim to try and leverage the already existing tools as much as possible and only build the extra bits that are needed for a good UX (eg. Generating the worklet file for the user automatically would be a good feature)

• How would one define a resource? As an object? Would this resource object include a specifier that describes the resource, like "some-file.css", "some-image.svg", or "http://unpkg.com/normalize.css"? Would this resource object also include a context that describes the current or active process referencing this resource? Like "file:/path/to/source.css", "file:/path/to/component.js", "http://unpkg.com/normalize.css", or "stdin:idk"?
• How would one define how resources are resolved? Here’s one example of a resolve algorithm. e.g. Use this tool to resolve the path and then use this other tool to read its contents.
• How would one define how resources are handled? e.g. Upon reading the contents of some imported resource as an AST, replace the current @import node with that AST.
• How would one define importers in a stylesheet, like @import, and how their resources are resolved and handled?
• How would one define metadata of a stylesheet? Could it be written into the stylesheet itself?
• Could this metadata include definitions for importers, resolution algorithms, etc.?