Last 12 weeks · 0 commits
4 of 6 standards met
Let's get some types up in here :) This PR adds a simple file which declares the type of the postal code object to be I considered setting up a literal type for the entire postal code object, so that you have an object that is indexed by a set of literals, not just , but I'm not sure how much value it really adds. Some devs may prefer not having to work with literals here, since in order to get a string out of the object you have to assert your string keys as index literals before indexing the postal code object: On the other hand, such a type would certainly be preferable to if your postal code is actually typed as a literal, not simply a string, for example if you have set up some kind of validation/sanitation pipeline. I think making such a type would work if we add this to : What are your thoughts on typing this module?
Repository: sindresorhus/norway-postal-codes. Description: Norway postal code registry in various formats Stars: 42, Forks: 10. Primary language: HTML. Languages: HTML (61.3%), JavaScript (38.7%). License: MIT. Homepage: https://sindresorhus.com/norway-postal-codes Latest release: v4.1.0 (3y ago). Open PRs: 0, open issues: 0. Last activity: 3y ago. Community health: 71%. Top contributors: sindresorhus, SimenB, braaar, radiovisual, Richienb.
By exporting it, it's easier to manually use in a script. Currently since it's async and runs as a side effect of being -ed we have to fake some waiting until the new files are written before checking of there are any new ones (we run a cron on CI checking if any new ones are available and update if so). One potential option is to only support node 14.8+ and use ESM and TLA