Giter VIP home page Giter VIP logo

Comments (15)

bhovhannes avatar bhovhannes commented on May 31, 2024 1

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.

bhovhannes avatar bhovhannes commented on May 31, 2024

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.

bhovhannes avatar bhovhannes commented on May 31, 2024

I've just published version 3.0.1 with the latest file-loader.

from svg-url-loader.

alexander-akait avatar alexander-akait commented on May 31, 2024

What is problem use ^ in deps to avoid future problems?

from svg-url-loader.

bhovhannes avatar bhovhannes commented on May 31, 2024

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.

alexander-akait avatar alexander-akait commented on May 31, 2024

No problem. It is bad practice for packages, it potentially case problem in future and better avoid this

from svg-url-loader.

bhovhannes avatar bhovhannes commented on May 31, 2024

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.

alexander-akait avatar alexander-akait commented on May 31, 2024

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.

bhovhannes avatar bhovhannes commented on May 31, 2024

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.

bhovhannes avatar bhovhannes commented on May 31, 2024

I've put ~ in version 3.0.2- https://github.com/bhovhannes/svg-url-loader/releases/tag/v3.0.2

from svg-url-loader.

alexander-akait avatar alexander-akait commented on May 31, 2024

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.

bhovhannes avatar bhovhannes commented on May 31, 2024

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:

  1. Configure renovate to send PRs about dependencies immediately instead of sending them once per week.
  2. Work on automated release when some of dependencies change.

from svg-url-loader.

bhovhannes avatar bhovhannes commented on May 31, 2024

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.

alexander-akait avatar alexander-akait commented on May 31, 2024

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.

bhovhannes avatar bhovhannes commented on May 31, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.