- Initial project folder setup:
mkdir mypackage # Create a new folder for your package
cd mypackage
pnpm init # Create a brand new package.json
pnpm add typescript vitest -D # Add Typescript (bundler) and Vitest (testing)
- create this file structure: (You can choose whatever file structure you want, this aims to keep things simple and somewhat "organized"
mypackage
|- package.json
|- src/
| |- main.ts # Here you can name this file whatever you want and add as much entry points as you want. again, for simplicity, we just have _one_ entrypoint
|- dist/
- Update
package.json
(see the file below) - Create a
tsconfig.json
file. I recomment you create the file withtsc --init
because it will create it will all the commented options with a small explanation - Update
tsconfig.json
(See the file below) - now you can install and build by
pnpm i
andpnpm run build
. - The build step will generate the dist folder and all the exported files you defined in the
tsconfig.json
file. - you can go to other project/package and
import {sum} from 'mypackage'
sum(4, 5) // 9!!!
- can asign any package name you want
- can assign any version you want
"type": "module"
is important for other projects to treat this one as a module. LOOKING FOR FEEDBACK HERE. It would be nice to understand better why we need this, I know is related to how the pacage will be treated (ESM or CJS) but I don't have a veru definitive answer to it.- the
exports
property is also important. This is the public access you are giving to other libraries/projects to use. it can be just"."
as in here, or you can have separate entrypoints defined. You at least need to define where is the file located, and the types is a must for IDEs like VSCode to now where to look for the package types. - the attributes
main
,module
andtypes
for some reason are important for VSCode in order to match the module with teh types. Maybe this is a legacy issue? (theexports
attributes is newer)
- I want the library users to bundle properly the package, not deliver it bundled. that's why the target is
ESNext
. (If you have more information about this it would be fine to get feedback too!) - you can read all the options, I decided to choose the most common and simple ones.
At Mintter, we have a monorepo setup for all the code, not just the frontend. Up until now we were putting everything frontend-related inside the same project.
In December we released the Mintter gateway, which is a server that can render Publications on the web, not just inside the local application. This is forcing us to separate some pieces of the app in order to use it on the gateway code (right now is a separate NextJS app).
While I was researching about how to create a separate package for the shared code, I found that it was hard to find a place in which the Simplest solution using Typescript was explained.
This Gist aims to share the process I follow to create a separate Typescript library that can be consumed inside another app/package. Please follow the steps and let me know if you have any feedback!
- Aarón shared publint which is a public package linter. Checkout the rules that it checks! (source: https://twitter.com/aarongarciah/status/1613168631822667779)