Our great sponsors
-
mol
Discontinued $mol - fastest reactive micro-modular compact flexible lazy ui web framework. [Moved to: https://github.com/hyoo-ru/mam_mol] (by eigenmethod)
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Open the first project we find using the modern module system: Module less than 300 lines, 30 of them are imports.
A good example is the JSON validation module family /mol/data. If you use the $mol_data_integer function anywhere in your code, the bundle will include the /mol/data/integer and /mol/data/number modules, on which $mol_data_integer depends. But, for example, the bundler will not even read /mol/data/email from the disk, since no one depends on it.
The beautiful idea of ​​Semantic Versioning is shattered by the harsh reality - you never know if something will break when you change a minor version or even a patch version. Therefore, many projects fix a specific version of a dependency. However, such a fix does not affect transitive dependencies, which may be pulled by the latest version when installing from scratch, and may remain the same if they are already installed. This confusion means that you can never rely on the fixed version and you need to regularly check compatibility with up-to-date versions of (at least transitive) dependencies.
Without versioning, the maintainer will get feedback from its consumers much faster and either release a hotfix or simply roll back the changes to better work them out. Knowing that a careless commit can break the build to all consumers, the maintainer will be more responsible for making changes. Well, either no one will use its libraries. And then there will be a request for a more advanced tooling. For example, this one: a dependency repository sends notifications to all dependent projects that a commit has appeared in a feature branch. They check the integration with this feature branch and if problems are found, they send details about them to the dependency repository. Thus, the library maintainer could receive feedback from consumers even before merging his feature branch into the master. Such a pipeline would be very useful for versioning too, but, as you can see, in the NPM ecosystem nothing like that is still not common. All because there is no urgent need for it. Rejection of versions forces the development of the ecosystem.
git clone https://github.com/eigenmethod/mam.git ./mam && cd mam npm install npm start
pack hello git \https://github.com/acme/hello.git pack home git \https://github.com/acme/home.git
pack hello git \https://github.com/acme/hello.git pack home git \https://github.com/acme/home.git