question-mark

Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Provide a combined `ampersand` module

See original GitHub issue

Issue Description

I didn’t know where to post this (which is part of the point I’m trying to make here), so I just posted it in what I think is the most important Ampersand module.

One of Ampersand’s primary features is that it is a collection of modules that can be used independently, and that there is no big module necessary. While this is a good goal design-wise, it poses some practical problems for Ampersand users like me:

  • My npm-shrinkwrap.json is currently 2300 lines long, 2000 of which are Ampersand. As someone who likes to be on top of all the dependencies of my production project, this scares me a lot. This is also not what one would expect from a ‘simple, no-magic’ framework. (Backbone.js only has underscore as a dependency).
  • I seem to recall only upgrading specific ampersand modules once or twice, and yet the dependencies of all Ampersand modules combined are all over the place: some modules depend on underscore, some on lodash.*, and I also see some other dependencies that could (and might have been already) be replaced by lodash.*.
  • Whenever I detect I need to upgrade a module, I’m too scared to do it these days. Especially if it’s a module that has some dependencies or dependents of other ampersand modules, I’m worried about what will break because of incompatibility, what other dependencies I’ll end up pulling in, etc. For example, I tried upgrading a module last week, but something somewhere else in Ampersand broke. I don’t know if it is actually a bug, or my own fault of incorrectly updating another module.
  • It’s hard for me to keep track of what changed to which ampersand module; every module is upgraded independently, no changelog is kept, so i would have to go through all the git commit logs of all modules I indirectly depend on. This means I only update when I spent some time discovering a bug myself, which is too late.
  • An extra problem in commercial settings is that each module’s dependencies (and subdependencies) need to have their license checked by legal teams. The size of the dependency tree in itself means this is a significant task, but this also makes it a hassle to update a single ampersand dependency, as it needs careful checking what the upgrade did, and whether it didn’t cascade other dependencies.

This is why I would like to have a combined ampersand module with all (or at least the most important ones with common dependencies) ampersand modules combined. Advantages:

  • This greatly simplifies the dependency tree in a project using ampersand, and simplifies mental tracking of the ampersand dependency.
  • Dependencies of Ampersand are maintained and updated in sync, so it’s easier to track those as well
  • Upgrading ampersand feels much safer, as I know that anything breaking will be a problem with code, not some strange interdependency problem or something I did wrong.
  • Keeping track of what changes in ampersand is easier, because I just have to look at the changelog / commit log / diff of a single project.
  • It makes it easier to report global ampersand issues such as this one, as there is an all-encompassing issue tracker
  • Probably not important, but combining usage may give a more accurate score on npm.js.
  • I’m not an Ampersand developer, but I can only assume that this would make some aspects of developing modules (especially upstream ones) and figuring out bugreports easier.

I’m not sure what the easiest practical way to get to such a module is. Maybe a first step could be to hand-pick a combination of modules+versions that play well together and have similar dependencies, and use a script that combines all these modules into a single module that is maintained separately. This would solve many of my problems. However, I think ultimately it would be simpler to have a lodash-like setup, where a single module is chopped up into smaller modules and published for those who like that sort of thing.

An extra optimization (which would simplify the dependency tree even more) is to depend on lodash as a whole instead of dozens of small lodash parts which in turn depend on several other lodash modules. If size of unused dependencies is a concern, tree-shaking could get rid of the unused lodash parts in the future anyway?

Issue Analytics

  • State:open
  • Created 7 years ago
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
cdaringecommented, Apr 26, 2016

yep, now i’m just outright in full support. keep bundle sizes lower, improve cross-dep deployments. i was short-sighted before, apologies. the recent npm unpublish fiasco, &-state upgrade version debacle, and lodash v3 => v4 bumps are all advocating examples.

@AmpersandJS/core-team, something to consider. long term, it would be nice to migrate to a lerna-like approach for version control & deployment.

0reactions
cdaringecommented, Apr 5, 2016

@remko, ya, i’m opening up to the idea. needing to review other teams’ monorepo formal approaches some.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Documentation - Ampersand.js
This module provides a pattern to address both those cases without having to rely on globals, or have circular dependency issues within your...
Read more >
How to combine parent using ampersand (&) with type ...
We can use any property of CSS by nesting a child element using the ampersand(&) symbol. Example 1: SASS / SCSS: ...
Read more >
Module scss ampersand class selector not working
webpack config module.exports = { ~~~ module: { ~~~ rules: [ { test: ... Providing you jsx code would help, but I will...
Read more >
Introducing Ampersand.js | &yet blog - AndYet
So we made Ampersand.js, a well-defined approach to combining (get it?) a series of intentionally tiny, and loosely coupled modules for building ...
Read more >
C. Reference manual for Administrative files - Mu2e
C.1.5 Module options, Regular and ampersand modules can take options ... CVS will provide the user with the two versions of the files,...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found