Maintaining simple utility functions yourself is less hassle than tracking external dependencies.
Some huge frameworks can ...
What is a pattern?
A pattern is not different from any other code you use in your application. The only difference is that somebody said "this is now called [x] pattern" and then that name has been universally accepted. If I say "Visitor Pattern" to another developer, they might just know what I am talking about.
>99% of programming solutions have not ...
This is the workflow that I currently use for a project with monthly releases.
After release, go through the dependencies and update those that have only minor changes and patch updates. Since npm follows semantic versioning, if the authors of the packages did their job fine, this should not break your system.
Perform a smoke test and if any dependency is ...
TL;DR: Don't kill a puppy, give it up for adoption instead.
The point of publishing a library is not the fame and glory. The point is contributing some useful functionality. Since you have published your work in a package manager, you have allowed others to depend on it.
The number of stars and downloads is irrelevant. Typically, many dependencies are ...
If it's an entirely private Node module, and it works for you, then go ahead.
However, I'd say the "correct" answer is No because if you published the module (even to a private corporate npm repo), you're now leaking deployment stuff into the app's configuration. Now you've given anyone that installs your project a way to mess with your build process.
Yes, you can. As johnrsharpe mentioned, this allows you to publish bugfixes on old versions, as well as concurrently release multiple testing versions.
Which is considered latest? From npm publish:
[--tag <tag>] Registers the published package with the given tag, such
that npm install <name>@<tag> will install this version. By default,...
A solution I see to this is having your CI/CD process on the main package ensure child packages are updated. Using semantic versioning you could set and fixate your package version major version and minor version number but ensure you always have the latest patch version.
This way, whenever a child package has a new patch, your build process will pick that ...
First, document the browsers you support. Below that include a section in your documentation about how to support older browsers. Here you can list the features for which pollyfills are required.
Internet Explorer 11+
Microsoft Edge 38+
Supporting Older Browsers
Perhaps a bit late, but for open source github repos there's https://greenkeeper.io/ it does exactly what you want, it opens a new PR for you every time a package has an update, which will automatically run whichever CI you have in place and test the updated version. It's up to you to merge or decline
I suggest you don't for the following reasons:
They can take up a lot of space in your version control system
They are unnecessary because these should be fetched as part of your build process
Usually you don't care about the history of these files
Typically version control systems handle binary data badly
The advantages storing them in source control are:
Here's a couple of things I see people do for any project:
Release a patch version that gives off a huge warning in the console that this project is deprecated, and no further support will be provided when it breaks.
Huge warning in README.md to reflect the deprecation. Reason can be written the README.md, on an issue, or on the wiki.
Set repo redirects ...
So you are really asking yourself if you can trust the publisher of that particular library.
In my view this arguement really cuts out 99.999% of all libraries and the minor ...
Will dependents who are building at lower node engine versions have any problems after my update?
That depends on how you are using that dependency that caused the update. If that dependency is only used in the testing of your package, but your package itself doesn't use it, then the users of your package will not be affected (at least not immediately).
What you're probably looking for is a Consensus Algorithm.
Consensus is a problem in all distributed systems. Consider the problem of data consistency in microservices. In an ideal world, each microservice has its own data store. Before microservices, we could count on there being one, centralized data store such as a database. There was a single source ...
No. Don't store them beside your source code. Most VCS are built to handle text files, not binaries.
However, you probably should set up your own local package server and have your build fetch your dependencies from there. It gives you the safety net to avoid problems like this. TL;DR: A guy unpublished 17 lines of code and broke the Internet. That wouldn'...