Steps to use it as your project

clone the repository.

open package.json and change all the property you need to change:

• name
• description
• author
• license
• repository
• other you want to change

run npx semantic-release-cli setup to configure your CI pipeline.

Obviously npm i

Hooks and CI

CI runs for branch master and develop

Git-Hooks: pre-push on master execute npm run build && npm run build-storybook, on develop execute npm run build

CI

Add semantic-release to manage versioning and publish on npm. npx semantic-release-cli setup CI is done with GithubAction, so when semantic-release ask what CI env, choose other. It gives you 2 tokens (GH_TOKENS and NPM_TOKENS) that need to be added as secret in github repo.

Semantic-release work with body of commit: look here for how to use it.

Or look in official conventional commits

Eslint & Prettier

Eslint from here, I just use npx eslint --init

Integrate Eslint with Prettier from here.

Now everytime I run eslint (eg npx eslint --fix src) prettier runs to fixing simple format errors.

EDIT: I don't need prettier at all, it usually conflicts with eslint config leading to indentations problems etc.

EDIT:EDIT: I need both, they are similar but achieve different goals.

StoryBook

I've mantain the same project structure from npx -p @storybook/cli sb init --type react.

I've add a webpack.config for use sass official doc

Gived Up

Probably what I'm trying to do is bad execute. The fact that I use JavaScript for developing and TypeScript for type definitions is a huge pain, mostly because I don't know how to integrate Storybook with that kind of project setup. That said a lot of library do this double work, keeping js only for developement and ts for exposing types to Typescript and IDEs. stackoverflow small disussion about this kind of problem Also is worth mentioning that strip off proptypes leave any JS project that use the library unable to type check which is sad.

Thing Discovered Step by Step:

• in package.json the field files let you specify what files/folder to publish stackoverflow
• in package.json the field main let you specify where your file with all the exports is. Default to index.js at root level offical doc
• browserslist is used by many tools (among them @babel/preset-env) to polyfill target browsers. Can be declared as file or directly in package.json. I copied the browserlist of default CRA. About different enviroment
• *.d.ts files are equivalent to header file (*.h) in C, as far as I understand they aren't mandatory but they're useful. They match exactly like .h files in C, so <FileName>.js needs <FileName>.d.ts.
• Inspired by react-bootstrap use a node script to build the library
• One problem I found is duplication between PropTypes and *.d.ts, they almost do the same thing: the first check types at runtime, the other at compile time. PropTypes should not be present in the library once published (don't know why but anyone does this way), so they're useful just for developement. Since I don't find anything (that really convice me) for generate .d.ts from PropTypes or viceversa, I stick with just *.d.ts and no PropTypes. This way you can use this library in a TypeScript project with checking, in a JavaScript project you don't get the checking but at least the suggestions from your IDE.
• I'm starting to notice the same problem as before, I'm duplicating my imports between index.js and index.d.ts and when exported as library only the *.d.ts are used. I suspect I need them for developing (with Storybook) EDIT: YES I NEED IT FOR DEV.

Dev Dependency

Building

• @babel/cli
• @babel/core
• @babel/preset-env: Do some crazy stuff for browser support.
• @babel/preset-react: Allow to transpile react.

• execa: utility for better interaction with shell commands
• fs-extra: utility for better interaction with filesystem
• @storybook/addon-actions: See action (eg click)
• @storybook/addon-docs: Auto generate Docs
• @storybook/addon-knobs: Let you change property dynamically from UI
• @storybook/addon-links: Allow to link between stories, useful for mocking a use flow (not our use case)
• @storybook/addons: Let you load Addons, nothing fancy here.
• @storybook/react
• @storybook/storybook-deployer: Let you easily deploy on gh-pages.