Support and document how to publish modules using Linaria to NPM

Background

Linaria is probably the best option to choose among CSS in JS libraries if you are making a component library which you want to publish on NPM.

• It produces vanilla CSS files, which means anyone can consume them
• It doesn’t have a runtime overhead, so regardless what solution the user uses for CSS, this is not going to another CSS in JS lib to the mix

Today I was trying to publish one of my libraries to NPM which uses Linaria but hit a couple of roadblocks. I hope we can address them.

Approaches

• Use single: true and ask users to take care of loading the CSS file
• Use single: false and require a bundler like webpack to load the CSS files
• Publish the source to npm and ask users to transpile their node_modules with Babel

Blockers

• The inserted imports are absolute paths, which make it impossible to share the stylesheets among different machines
• The class names might not be unique because they are based on developer’s folder structure, so if two people named “Dave” have same folder structure, e.g. Users/Dave/projects/components, but have libraries with different names, the class names might clash

Proposal

• Convert imports paths to be relative to the file, pretty-straightforward (#180)
• It’s impossible to generate globally unique names, but we can have some logic so that the hashes include the package name, for example: instead of src/App.js, we use awesome@version~src/App.js to generate the hash, where awesome is the name of the package and version is the version of package we read from package.json if it exists, this assumes package names are globally unique. This won’t work properly in some scenarios where the styles changed but version number didn’t (e.g. installing from git), but it’s impossible/extremely hard to do it.

Currently, I only need the first one, which should be easy to fix. Appreciate your thoughts.

We also need to document the process of publishing libraries using Linaria to NPM.

[oliviertassinari]

@satya164 We will release a stable version of Material-UI v4 in the next few weeks. I want to prepare for v5. We have recently made a developer survey. Aside from people asking for more components and better documentation (something we can fix between v4 and v5), a lot of people are asking for a better customization story, faster components, and a smaller bundle size. We will probably drop IE 11 in Material-UI v5. Edge’s recent move to Chromium should enable a IE 11 to Edge migration on the older Windows platforms. It’s not possible with the current Edge architectural decisions. It should be possible going forward with Chromium. So, I would expect IE 11 usage to really fade in a year or two. Linaria could be an incredible fit for Material-UI v5.

If only we can figure a great integration with npm, something that made Material-UI move to CSS-in-JS two years ago. Back at the time, CSS-modules support was hard to configure.

[rakeshpai]

Just checking to see if there has been any movement on this? I want to create a library of components, and want to know the best way to ensure that consumers only bundle the CSS they need based on the components they’ve imported. I’m not familiar with Linaria internals, but I’m available for help.