![]() ![]() the unpkg field you can define the default file, which get served if someone includes. It's a CDN so people can pull your scripts into their scripts without installing them over npm. If you publish your lib on npm it will be available over unpkg. "main": "dist/my-awesome-lib.js",Īnd if you publishing node modules, you will be fine with this one.īut if you’re going to publish something for the browser there are more fields to know.įor example the unpkg field. If you transpile your source or bundle it, you can define the dist file there. There you can add your for example index.js. The basic entry point will be defined over the main field. Is it a node module? Is it a browser plugin? This one heavily depends on the type of your package or lib. This way you give the user freedom to chose the version and upgrade the dependencies. There would be a peerDependency version mismatch but as long, there would be no breaking changes it would work. Prefered version is 2.1.x If someone would install webpack 2.2.x your plugin would mostly work, too. With peerDependencies you say, Hey look, you need webpack to run my plugin, so install it please. ![]() You would have to update your package.json on every release of a new webpack patch and update the dependency version. If you would add webpack as a dependency the user would have installed two versions of webpack the one which he got installed already for his build process and the one which comes with your plugin. For example you want to write a plugin for webpack and you use some functions of webpack and extend them. Because it requires the user to have the dependency installed already. PeerDependencies are mostly used if you write a plugin for something. This is important, because if someone installs your package over yarn add my-awesome-lib the devDependencies does not get installed! So if you add request as a devDependency and somewhere in your code you have an import request from 'request' this will not work. Like eslint or xo for linting or karma or ava for testing. Because it is needed for your code to run properly.ĭevDependencies are the one, which are required for the development. So if you writing an API or a service and you’re using for example request it is a dependency. it is important to get your dependencies right.ĭependencies are required for your lib to work. However if you want to publish a package, a lib, a vue component etc. Because they get bundled into a browser build most of the time. Now if you work on a project like an app or website, it does not make such a big difference if you add your dependencies as a dependency or devDependency. Or save them as devDependencies with yarn add or yarn add -D So we all know that you can add dependencies to your project. You can also add keywords which help people to find your package if they search for something on □ Dependencies So people can report bugs and know where to request features. You should also add the repository field, with a link to the github repo and you can also add the bugs field with the link to the github issues page. So they know if they can use it in commercial projects, what are the restrictions and so on. However if you want people to use your package, maybe even in bigger projects you definitely should add a license. People often think it's not that important. I guess the license field is one of the most forgotten fields. It's common to add it in the form of Name. In the author field you add your name and e-mail, so people know who published the package. Npm search shows title, username, version and description defined in your package.json People will read it if they search for your package on In the description field you should add a quick and on-point description, about your package. And there is no worse feeling then breaking peoples production code because you introduce breaking changes but only change the patch version of your package. Because maybe a lot of people will use your package. The version tag defines the version of your package. The name field defines the name your package will have in the registry and people will install your package over the name you define there. ![]() Furthermore you save also relevant information about your package in this file. You know that all dependencies get saved in your package.json. □ But before we do this, we have still some points on our □checklist. If you now want to publish your package on npm there is a simple command for that: npm publish You installed them with npm install XYZ or if you're super cool □ with yarn Let’s assume, you already use npm for your dependencies. So, you have finished a lib, cli tool, component or some other scripts to want to share with the world.□ So it is time to publish it on npm. An in-depth guide on how to publish your modules on npm, without pain. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |