Comments (15)
Really, look on other popular repos and you can see 99% deps are using ^. Do you think they are all mistaken?
I don't really care about how popular repos are doing things. It's a thing you should look at, but being popular does not mean they all are doing things right. We had 3 cases when karma dependency specified as ^
caused build issues for us (at that time we were not using lockfile). If karma used pinned versions down the dependency tree, we won't have any issue, even without lockfile.
Problem what you potentially spread version with bugs or vulnerabilities.
Everyone, always, spreads versions with potential bugs or vulnerabilities. The problem is how fast he will fix security issues.
With fixed (and latest) dependencies I publish version which works and doesn't have any security issues, unless found. When someone finds a security issue, he releases a new version, I update the version number in my package and everything is fine.
I've already changed to have ~
as packages usually publish patch versions when they fix security issues. I think it is extremely rare to publish minor version for fixing security issue and it is not a good practice by definition: "PATCH version when you make backwards compatible bug fixes." (this is taken from https://semver.org/)
There is a lot of documentation about this, Iβm not the first time explaining this and you really can easily find articles about it.
I think we don't understand each other. As I've said, send me the link to the long, detailed article you already agree with. Perhaps after I'll go through it, it will make conversation more productive.
Otherwise I am going to lock this issue as this conversation seems to be going nowhere.
from svg-url-loader.
I've renovatebot configured which keeps dependencies updated, however sometimes I forget to publish new version of svg-url-loader when dependencies change.
I'll publish one now.
from svg-url-loader.
I've just published version 3.0.1
with the latest file-loader.
from svg-url-loader.
What is problem use ^
in deps to avoid future problems?
from svg-url-loader.
I don't see the problem with fixed version, except having 2 versions of file-loader in node_modules.
Did you had any issues with version 3.0.0 of svg-url-loader?
from svg-url-loader.
No problem. It is bad practice for packages, it potentially case problem in future and better avoid this
from svg-url-loader.
I see the point in specifying ^
in order to make it clear that svg-url-loader
works with all 4.x.x versions of file-loader
.
However I don't see what problems/bugs may happen if I leave the exact version. Even more, it is possible that version 4.3.0
of file-loader
will introduce a bug and if I put ^
in svg-url-loader
dependencies, consumers without lockfile will get that bug during their next npm install
.
By specifying exact versions, I am sure that my package will always work, unless the versions of file-loader
and loader-utils
will become incompatible with the current version of webpack.
If you can describe a possible scenario when keeping exact version will cause a problem (by saying "problem" I understand the broken build or something like that), please let me know.
from svg-url-loader.
However I don't see what problems/bugs may happen if I leave the exact version.
Seriously?
- For example we can have security problem and fix it, now you need do release, if you are unavailable, such as on vacation or ill, you will potentially supply a vulnerable version
- We can change hash algorithm, but loader still will be generate old hashes, which may lead to ineffective Long Term Caching
- A lot of other scenarios, if you need i can write them
By specifying exact versions, I am sure that my package will always work, unless the versions of file-loader and loader-utils will become incompatible with the current version of webpack.
No, because transitive dependencies (packages used inside file-loader/loader-utils/schema-util/etc) can introduce bug also and you can't control them. Therefore, the scenario that you described is simply useless, it will not protect you from bugs and problems. I would say that using exact versions
is more dangerous than ^
. Look on popular projects, they used ^
, rare ~
and never exact versions
(exclude some specific packages).
Remember - using exact versions
is not protect your software.
from svg-url-loader.
Seriously?
- For example we can have security problem and fix it, now you need do release, if you are unavailable, such as on vacation or ill, you will potentially supply a vulnerable version
- We can change hash algorithm, but loader still will be generate old hashes, which may lead to ineffective Long Term Caching
- A lot of other scenarios, if you need i can write them
I agree with all that scenarios, but here we'll only have issues if I will not release a new version after each release of file-loader
.
No, because transitive dependencies (packages used inside file-loader/loader-utils/schema-util/etc) can introduce bug also and you can't control them. Therefore, the scenario that you described is simply useless, it will not protect you from bugs and problems. I would say that using exact versions is more dangerous than ^. Look on popular projects, they used ^, rare ~ and never exact versions (exclude some specific packages).
Remember - using exact versions is not protect your software.
There are 2 types of svg-url-loader consumers - type A - people having lockfile and type B - people without lockfile.
Let's consider both cases:
A) Consumer has a lockfile. He has pinned all dependencies via lockfile and even if I will have ^
in my package.json, his lockfile will always install the same version of svg-url-loader
and file-loader
. I guess nowadays this is the most common scenario as everybody should use a lockfile.
B) Consumer does not have a lockfile. Assuming I have ^
for file-loader
in my package.json, during each install he will get some version of svg-url-loader
and the latest version of file-loader
. That should be fine in a perfect world, where everybody follows semver and has 1000% reliable test suite. However I saw many cases, when even patch change broke something.
Here is why I prefer to have exact versions. Yes, I agree, security patches and bug fixes may come with some delay in that case. But as a maintainer of svg-url-loader
it will be predictable which combination of svg-url-loader
and file-loader
consumers are using.
With all that said, the correct way of going forward is to find a balance between staying safe in terms of knowing exact "last working" combination of (svg-url-loader
, file-loader
, loader-utils
) triple and allowing consumers to upgrade on their own by loosening restrictions in svg-url-loader
's package.json.
And for me that balance point is specifying ~
for dependencies in package.json
.
from svg-url-loader.
I've put ~
in version 3.0.2
- https://github.com/bhovhannes/svg-url-loader/releases/tag/v3.0.2
from svg-url-loader.
Using ~
not solve problems because new features is unavailable and some fixes can be done only as minor
release (look in semver).
And A and B still have problems with transitive dependencies because you cannot control them.
A lot of articles on reddit and medium from yarn and npm developers about this. You can find them using google. Using specify
version (like you used only recommended for application, but you package is not this type).
As a mini, I had to create a new issue about what you should do release, it is not known how much time would have passed before you noticed this if i hadn't done it, as a maximum it does not protect against bugs.
There is nowhere to look for balance, there are clear recommendations for use and itβs better not to invent anything but use them.
from svg-url-loader.
There is also a possibility of security fixes which require breaking changes and that will be a major bump. That does not mean I have to put *
in my package.json
, right?
If you have a link to a detailed article covering all pros and cons of both approaches I'll be more than happy to go through it.
Understand me right, I am always glad when someone points me that something can be improved and thank you for opening this issue. That made me think about what can improved in my dependencies.
However, assuming I update this repo on a weekly basis (renovate is configured to send me weekly PRs), and I have only 2 dependencies, which does not update very often, and I've already put ~
in package.json, I see no point to continue this discussion without having concrete bug report with reproducible steps on the table.
On the other hand I'll put the following 2 items in my TODO list:
- Configure renovate to send PRs about
dependencies
immediately instead of sending them once per week. - Work on automated release when some of
dependencies
change.
from svg-url-loader.
And A and B still have problems with transitive dependencies because you cannot control them.
A does not have problems with transitive dependencies, because lockfile locks all versions of packages in dependency tree. That is why lockfiles have been designed for - to make people install the same versions of every package (including their dependencies and dependencies of their dependencies) every time they run npm install
or yarn
from svg-url-loader.
That does not mean I have to put * in my package.json, right?
No, you should use ^
to allow minor releases
A does not have problems with transitive dependencies, because lockfile locks all versions of packages in dependency tree. That is why lockfiles have been designed for - to make people install the same versions of every package (including their dependencies and dependencies of their dependencies) every time they run npm install or yarn
Update lock file will create a problem, and believe me, all repositories do the update. Also when something bump and transitive deps also will be bumping, so protecting using specify
version is not helping
You can configure renovate
and update deps even you use ~
/^
then configure renovate to automatically merge if CI green (less time on merge and easy to catch regressions)
Problem is not in updating and how other you do it. Problem what you potentially spread version with bugs or vulnerabilities. I do not see any benefits of using specify
version or ~
. Really, look on other popular repos and you can see 99% deps are using ^
. Do you think they are all mistaken? There is a lot of documentation about this, Iβm not the first time explaining this and you really can easily find articles about it.
from svg-url-loader.
BTW, I've configured renovate to upgrade file-loader
and loader-utils
as soon as they'll have a new version (see 951bf3f)
from svg-url-loader.
Related Issues (20)
- Integrate SVG-O to strip out unnecessary lines embedded in svgs HOT 2
- How to use this in html? HOT 2
- Images svg aren't loading, how to fix? HOT 2
- Incorrectly escapes # in style-element HOT 3
- Question: is there a way to disable plugin inline for few SVG? HOT 1
- Update README to include webpack options configuration for supported parameters HOT 2
- The benefits of data:xyz style vs. SVG sprites HOT 1
- [Proposal] Add option to skip some phrase during encoding HOT 1
- Issues to find SVGs inside imported sass files. HOT 1
- Please update `file-loader` to latest version HOT 14
- Incorrect Data URI content when using issuer test HOT 2
- Doesn't working on image tag HOT 2
- Missing webpack in peerDependencies for yarn@2 compatibility HOT 1
- Please Add CHANGELOG.md HOT 1
- Action Required: Fix Renovate Configuration
- [Webpack]Error report of introducing SVG file into img tag ? Please refer to the screenshot. HOT 13
- "module export" instead of svg directly HOT 6
- Dependency Dashboard
- Malformed svg produced HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from svg-url-loader.