npm: How to ensure the visible result of the changes made when writing css libraries and dom libraries?

Suppose you are writing an npm library, an analogue of the bootstrap framework, which includes styles and scripts. The question arises: how can you see the result of your work with your eyes during development? In the question I indicated "css and libraries working with dom" because I talk about such libraries that give the result that is visible in the browser, and if we write just some utilities, then the problem is solved by writing a unit test.

I will explain in detail what problems I would like to solve.

Of course, you can configure the gulp-file, register the compilation of css-preprocessors, build scripts webpack-ohm, monitor files with automatic reassembly and reboot the browser and so on. Under each group of components, such as buttons or input fields, we make a separate html page, where we will check the display in the browser while editing styles and scripts. As a result, the library will immediately acquire files that users do not need.

You can not commit these unnecessary users files to the repository. But what if several people work on the library? Probably, to make a separate branch of development ... This branch requires more npm dependencies than the master (gulp, preprocessors, webpack, browser reload, etc.), and therefore, when switching between branches, you have to reinstall the npm dependencies each time.

But the real hell will begin when the library is already ready for use, while, as usual, it will initially reveal a bunch of bugs and flaws. The vicious circle will consist of the following links:

1. Began to use the library in the project - found a bug.
2. They closed the project - they opened the project with the library.
3. Corrected the code.
4. If we do not have the means to view the results, then we can check whether we corrected, for example, the styles of buttons or input fields, only in the project where the library is used.
5. Commit the patch to the remote library repository.
6. We update dependences in the project where this library is used.
7. See the result

If it turns out that you need to tweak a little more, or a new bug is found, you will have to repeat all the steps listed above.