Pete Gonzalez

In [Gitter today](https://gitter.im/web-build-tools/web-build-tools?at=5d71af113b1e5e5df15d47bc), @renoirb brought up another potential application: Reduce copy+pasting of common package.json contents throughout the monorepo. For example, certain versions could be centrally specified, to simplify upgrades: ```js...

CC @MickeyPhoenix who was interested in specifying dependency versions in one place.

If https://github.com/pnpm/pnpm/issues/3316 "workspace tags" are not implemented by the package manager, perhaps it could be applied by the proposed **package-rush.json** transform.

Yes, looking at this more closely, it is safest for `rush version` to always bump the downstream projects. But in many (most?) cases it is clearly wasteful. > Just removing...

In order to improve this, we need to decide on the best design. > For example - a project that bundles another project, with the bundled project listed as a...

> Might another option be to build if a dev dependency has changed, and store a hash of all the package files that aren't npmignored in changelog.json? Then if the...

Seems like the discussion has progressed enough that someone could create a PR to test out this idea. We currently have 38 open PRs, so right now the maintainers should...

First steps: 1. We need someone to make a small PR that blocks `--change-projects-only` when `buildCacheEnabled=true`, referring people to this GitHub issue 2. The tentative name `git:LAST_BUILD` probably conflicts with...

**material-ui**'s package.json files violate at least two specifications for this file: - **CommonJS**: `name` and `version` are required fields: http://wiki.commonjs.org/wiki/Packages/1.0 - **NPM**: `name` and `version` are required fields: https://docs.npmjs.com/files/package.json >...

> This defines the top-level package.json. It does not specify how nested package.json should look. How would we detect a "top-level" package.json? Node.js module resolution works by crawling directory trees....