We need something akin to this (this is a shell script to FIX it, but we need something to prevent it in boll):

for p in packages/*/package.json;
do
  # if package has no peer dependency ignore it
  jq -e '.peerDependencies' $p >/dev/null || continue;
  # for each peer dependency
  for pd in $(jq '.peerDependencies | keys[]' $p);
  do
    # if package does not have a corresponding dependency, ignore it
    jq -e ".dependencies[$pd]" $p >/dev/null || continue;
    # remove peer dependency
    jq "delpaths([[\"peerDependencies\", $pd]])" $p > tmp
    mv tmp $p
    # if peerDependency field is not empty, ignore it
    test "0" = $(jq '.peerDependencies | keys | length' $p) || continue;
    # remove empty peerDependency field
    jq "delpaths([[\"peerDependencies\"]])" $p > tmp
    mv tmp $p
  done
done

Given

Package A

export interface Foo {}

Package B

import { Foo } from 'A';

{ "devDependencies": { "A": "0.0.0" }}

Expected

Runs with no errors

Actual

TransitiveDependencyDetector complains that 'A' is not properly declared as a dependency

Use syntax described in https://docs.microsoft.com/en-us/azure/devops/pipelines/scripts/logging-commands?view=azure-devops&tabs=bash#formatting-commands to print out errors and warnings in alignment with usage in VSO.

Expected

[TransitiveDependencyDetector] /foo/index.ts:10 "@foo/bar" is used as a module import, but not listed as a dependency. (Either add as a direct dependency or remove usage.)

Actual

[TransitiveDependencyDetector] /foo/index.ts:0 "[object Object]" is used as a module import, but not listed as a dependency. (Either add as a direct dependency or remove usage.)

There are rules which we could potentially enable fixers for.

Imagine if the rule had an API such as...

const someRule = {
  check: async (filename, options) => {
    // make an errors array
    return errors;
  }, 
  fix: async (errors, options) => {
    // do some stuff to fix the error
  }
}

export const someRule;

This is similar to how manypkg works here...

And how eslint rules work as well such as here...

TransitiveDependencyDetector seems to get tripped when it is looking at something like this:

@foo/bar/baz

Where the package name is @foo/bar and the path is baz

Running boll with certain lib output containing d.ts files can result in output like:

ERR! [TransitiveDependencyDetector] D:\git\ooui\m\packages\excel-online-cardview\lib\webpack\resjsonBundlerWebpackPlugin.d.ts:0 "webpack" is used as a module import, but not listed as a dependency. (Either add as a direct dependency or remove usage.)

d.ts files contain type information only, are not executable files, and should be universally ignored in rules that apply to executable code.

Specifically here, any imports in d.ts files can be safely concluded to be types-only imports and should not be considered for certain rules, such as TransitiveDependencyDetector.

In order to help create a "pit of success" for best practices in a monorepo, let's create a standard set of "best practices" type rules.

Once the rules are created, let's also add a new reporter which can return return the results of running the monorepo checks. IN that weay, repository owners can run the boll monorepo best practices checks to see how their repo aligns.

In my local configuration, I should be able to write:

{ ruleSets: {
  ruleName: {
    include: ['./src/**/*']
  }
} }

and it should entirely replace the patterns that the default glob implementation would run.

As a developer,
When I write code that is not a best practice but not a build break,
I would like a "warning" message that is not an error.

There's several new pieces of functionality that need to be updated in the docs.

• How to use addRule
• How to use the bootstrap function of a plugin
• Auto loading of plugins
• There are two ways to run boll, at monorepo root or against individual packages

• Package name should match package directory name.
• Packages must specify version
• Packages should be private by default (maybe warn users somehow? not sure how to "enforce" this)

For a given package, highlight any packages that are included but not used.

Would need to support a list of exemptions for globals that are ambient imports.

Similar to how eslint works, the "extends" option should be able to take an array, instead of only a single rule set.

Many webpack.config.js module.rules loader configurations would have an explicit excludes of a /node_modules/ pattern. We should allow these kinds of references. I think maybe we should only have the detector deal with things inside a require() or import statement. This will make the rule not catch 100% of stuff, but it can at least allow the proper uses of these node_modules appearances. Alternative is to have disable-single-line kind of thing so that we don't have to disable the entire rule altogether.

What?

For specific sections of package.json files, ensure that all dictionary entries have corresponding entries in a rationale section.

Why?

As JSON does not allow comments, it is difficult to annotate tricky or dangerous lines in package.json files. Content of certain sections (such as resolutions) often carry increased risk, and there is a desire to have inline annotations for other developers' benefits.

Rule specifics

The default configuration of the rule should cause a failure on the following package.json

{
  "name": "foo",
  "resolutions": {
    "transitive-package-1": "0.0.29",
  }
}

The failure should clarify that "a rationale entry for resolutions.transitive-package-1 was expected, but was not found".

The default configuration of the rule should succeed on this fixed version of the previous file:

{
  "name": "foo",
  "rationale": {
    "resolutions": {
      "transitive-package-1": "needed because of issue with dependency-package-2",
    }
  },
  "resolutions": {
    "transitive-package-1": "0.0.29",
  }
}

package.json files that have no need for a rationale entry (because of no declared resolutions for instance) should succeed as well.

Configuration options

• rationaleRequiredList - a list of keys in package.json that require a corresponding entries in rationale.
  Default value: ['resolutions', 'workspaces.nohoist']

Test files should be granted more permissive access to imports than product code.

For instance, this code is fine in a test:

import { promisify } from 'util';

However, would cause problems if packaged and evaluated in a browser.

This rule should handle these scenarios cleanly without the need for special cases or updates to manually maintained lists in the future.

Perhaps the cleanest solution is to not run this rule on files that are not "shipped" from a package. However, given multiple build pipelines (typescript, webpack, etc), it can be difficult to determine if a file actually ends up be exported.

We should have at least an option to only run the boll rules against git controlled files. Otherwise, we'll run into issues dealing with a repo that needs to move onto something that has a strict file access requirements like BuildXL. So, for example, it is not good to have a linter that is run all in parallel with no topological ordering that COULD access files that are built. This means that the boll linter does slightly DIFFERENT things against a repo that has been BUILT vs something that is CLEAN.

Expected:

If I inherit a ruleset with an exclude directive and declare my own, the exclude settings should be merged.

Actual:

The downstream exclude setting takes over and becomes the only definition.