Publishing an npm module will be in the checklist of most budding javascript developers. After all, we would have used plenty of npm modules ourselves, saving us hundreds of development hours and making our lives much easier. It is only obvious for us to think about contributing back to the community we owe.

To be true, publishing one is relatively simple. But getting an idea for one, which could prove to be useful to the community (in theory at least ;) is relatively harder. There’ll already exist an npm module for most problems we could think of. In fact, like how apple trademarked “There’s an App for that™”, Npmjs could file a trademark for “There’s an npm module for that”.

Coming to the actual story… I was developing a react native application a few weeks back. I had to develop a custom component which would enable me to search a FlatList since there is no built-in support for search. Then, this idea of releasing it as an npm module was bugging me. Because finally, I had something which could be a little useful to someone facing a similar problem.

So, I started making the component much more generic and added support for SectionList as well. Then I began exploring ways of releasing the package.

The first step is to initialize an npm project using npm init and providing it with the necessary info.

The next step is to determine the modules which our package will be dependent on. In my case, it was just react and react-native. But since anybody who would be using this npm module would be doing so in their react-native project, they must already have react-native installed. So, these must be added to peerDependencies instead of dependencies. Apart from these, I didn’t have to use any other modules since the problem was relatively simple.

Then we would have to worry about versioning our modules so that we could release bug fixes, feature updates.. with ease. The standard is to follow semantic versioning.

The patch version must be incremented when doing a bug fix. Minor version when we do some minor feature enhancements without breaking the API. Major version change occurs when we do a** breaking change** to our module.

The next step is to organize our code. The entry point would be the one we specified in package.json. By default it’d be index.js. We could organize it in whichever way we find comfortable.

The final step is to prepare a useful README.md so that, people who actually would want to use our package fell at ease.

Once we have everything in place, we’ll have to check if our package really works. Since it's not published yet, we’ll have to test it by installing - giving it the file path instead of the name of the package. Something like npm install <file-path> would do the trick.

If everything works fine, we’re good enough to publish it to npm. It's as simple as npm login && npm publish if we have an account with npmjs already.

Here's the link of the modules in npmjs.

I also went a step ahead and created a react-native application that demonstrates the functionalities of this module. This application also helped me a lot in the documentation efforts.

git clone https://github.com/Chandrasekar-G/RNSearchableListDemo.git
cd RNSearchableListDemo
react-native run-ios 

TODO

1. I’ll have to write unit tests using jest. I began testing my components with jest snapshots. But I just wish to be sure so that I write unit tests actually solve to be useful instead of writing them for the sake of it.
2. Once jest tests are ready, add a CI preferably Travis.
3. Adding support for highlighting the text matching the search term.

Feel free to try out this module. Any constructive feedback/pull requests are
welcome :)

npm i react-native-searchable-list --save

import