Bit's default target compilation for components

[itaymendel]

There are several compilation targets teams can agree on, this thread covers Bit's default configuration for shared components and the reasoning behind it. It is possible that some framework support will do things differently, but generally this is the extent of our experience with code-sharing as dependencies and outlook on the current state of the eco-system.

IMPORTANT - using the same target compilation does not mean one can use a React component within an Angular application. To achieve this, one will need to supply a complete runtime for that React component in their Angular application. There's several tools and methodologies that can help with that.

The below part was originally written by @qballer here.

The problem with sharing components

When writing a shared code, there is a need to agree on the consumption method. For example, when developers who write vanilla code would like to share it with TypeScript teams (and vice versa). In most cases, even similar flavors of components may have different needs in terms of configurations and dependencies. To collaborate well, we would like to decouple the logic from the way we build and test. This way, we can apply fixes and move around the code base with little consideration to every build and test detail. This is a problem faced by any team that attempts to write a shared library of components.

Target Compilation

We use tools like WebPack and Rollup to bundle a web application to a single target that contains all dependencies and assets. It is the application's responsibility to create runnable bundles for the browser. Components should only be compiled to a reusable target a bundler can consume. This process has several benfits:

• No bundled duplicate dependencies.
• No loss of data (CSS classes turned to hash).
• Enhances bundler features like tree-shaking and code splitting.

If we accept this reasoning, the ideal target format for components is - ESM2015.

While there are still gaps in support of ESM2015 by browsers, bundlers handle this module system very well.

Shared styles

It is essential to understand how component sharing works with the different techniques of styling in Web development. Each technique affects the consumer differently.

Native CSS

This method refers to having a basic .css file alongside the component. While there are inherent issues with the global scope, which makes it inadvisable for styling components, some projects still prefer this method (some issues can be resolved with BEM or other methods).

When such method is used, the consuming app should handle it by bundling the .css files of its dependencies. This is why when an Environment finds this type of file, it merely copies it and ships it with the transpiled output of the component.

Style pre-processors and CSS Modules

This method refers to using CSS transpilers like Less, Sass and Scss. Using such tools is very helpful, as different bundlers can use these styles to create vars, scoped classes, and other features. This styling method, much like the way native CSS works, needs to be managed by the consuming project's bundler. This is usually done by configuring a specific plugin that handles the type of pre-processor.

CSS in JS

CSS-in-JS is a methodology that uses Javascript objects which describe the different styles. It styles the component during runtime, while the JavaScript code is being evaluated. Components designed using this method should be handled like any other JavaScript code. Unlike the previously discussed styling options, here, the consumer does not need to do anything, as Bit already transpiles the JS objects alongside the implementation itself.