AmpersandJS / ampersand-version

Versioning for ampersand-modules
MIT License
1 stars 2 forks source link

Simplify dependency tree #7

Open remko opened 8 years ago

remko commented 8 years ago

Looking at npm-shrinkwrap.json, the dependency tree of ampersand-version is quite large because of the through2 dependency (see below). For a module that isn't supposed to do much, and that every other ampersand module depends on, this is annoying, because it makes the entire tree of a project that depends on ampersand (uselessly) explode (which worries me as a maintainer of a project). Could the through2 dependency be avoided?

The dependency tree looks as follows:

   "ampersand-version": {
      "version": "1.0.2",
      "from": "ampersand-version@^1.0.0",
      "resolved": "https://registry.npmjs.org/ampersand-version/-/ampersand-version-1.0.2.tgz",
      "dependencies": {
        "find-root": {
          "version": "0.1.1",
          "from": "find-root@^0.1.1",
          "resolved": "https://registry.npmjs.org/find-root/-/find-root-0.1.1.tgz"
        },
        "through2": {
          "version": "0.6.5",
          "from": "through2@^0.6.3",
          "resolved": "https://registry.npmjs.org/through2/-/through2-0.6.5.tgz",
          "dependencies": {
            "readable-stream": {
              "version": "1.0.33",
              "from": "readable-stream@>=1.0.33-1 <1.1.0-0",
              "resolved": "https://registry.npmjs.org/readable-stream/-/readable-stream-1.0.33.tgz",
              "dependencies": {
                "core-util-is": {
                  "version": "1.0.2",
                  "from": "core-util-is@~1.0.0",
                  "resolved": "https://registry.npmjs.org/core-util-is/-/core-util-is-1.0.2.tgz"
                },
                "isarray": {
                  "version": "0.0.1",
                  "from": "isarray@0.0.1",
                  "resolved": "https://registry.npmjs.org/isarray/-/isarray-0.0.1.tgz"
                },
                "string_decoder": {
                  "version": "0.10.31",
                  "from": "string_decoder@~0.10.x",
                  "resolved": "https://registry.npmjs.org/string_decoder/-/string_decoder-0.10.31.tgz"
                },
                "inherits": {
                  "version": "2.0.1",
                  "from": "inherits@~2.0.1",
                  "resolved": "https://registry.npmjs.org/inherits/-/inherits-2.0.1.tgz"
                }
              }
            },
            "xtend": {
              "version": "4.0.1",
              "from": "xtend@>=4.0.0 <4.1.0-0",
              "resolved": "https://registry.npmjs.org/xtend/-/xtend-4.0.1.tgz"
            }
          }
        }
      }
    }
  }
},
latentflip commented 8 years ago

Curious whether anyone on @AmpersandJS/core-team @AmpersandJS/community-leaders finds what this module provides valuable?

One key issue with it, is that in its current form it requires the end user to be bundling with browserify (I don't think webpack runs the transforms by default?) so currently it's not doing anything if you use e.g. webpack (which is growing for sure).

So we should probably either implement #1 or just drop it?

Thoughts?

remko commented 8 years ago

I would also note that I expected this functionality to be something handled in the build/prepublish of each ampersand module itself, instead of pushing the task of running the version string patching to the build of Ampersand users. This would make it entirely independent of any build system used, would probably be safer and more robust, and wouldn't burden the users with useless extra dependencies or transformations done at build time.

As an ampersand user already struggling with dependencies, I would suggest to either drop it, or reorganize ampersand modules to use it as a build step and only include it as a devDependency; as long as the dependency is gone for the end user, I'm happy.

latentflip commented 8 years ago

Shoulda woulda coulda ;)

Philip Roberts

On 24 Dec 2015, at 11:57, Remko Tronçon notifications@github.com wrote:

I would also note that I expected this functionality to be something handled in the build/prepublish of each ampersand module itself, instead of pushing the task of running the version string patching to the build of Ampersand users. This would make it entirely independent of any build system used, would probably be safer and more robust, and wouldn't burden the users with useless extra dependencies or transformations done at build time.

— Reply to this email directly or view it on GitHub.