Relevent when:

somebody makes a new directory for packages

e.g.

/packages/collection/a

where both collection and a are new directories. The necessary tsconfig.setting.json file should look like

{
    "extends": "../tsconfig.settings.json"
}

and live at /packages/collection/tsconfig.settings.json so that it is imported by /packages/collection/a/tsconfig.json.

Question: which package should take this responsibility? I guess it could a new package but we should consider the DX of opting in to these hooks

use case: we need to pin only the "typescript" dependency version, no other versions, but bootstrap does not have a mechanism by which we can ensure this.

call the tool before bootstrapping and have it error out if versions of the designated packages are not hoistable (even when hoisting is not enabled)

probably a breaking change to the args?

currently using amber for this, but would be nice to have

use case: we use regexes in the lerna manifest but want to use the make packages functionality without manual modification

https://dave.cheney.net/2019/01/08/avoid-package-names-like-base-util-or-common

this likely indicates a user error, e.g. forgot to add the package scope, and should not fail silently (currently returns an empty array)

into the monorepo

archive all the other projects in this github namespace

I know this because I tried to call hoistedPackages with a path to a cousin directory (I was not in a monorepo at the time) and I got an error about "could not find lerna manifest upwards from current directory"

Use the current working example

use case: run in a pre-commit hook to ensure we've caught all parts of a TODO

🚨 The automated release from the beta branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the beta branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

e.g. with target prerequisites

Currently defaults to 4

otherwise it seems concurrency issues cause unnecessary diffs

for consistency

• avoid independent clean/build of each package during publish

Something like fp-ts's release script to prohibit npm publish:

• clean all
• lint all
• pin
• build all
• test all
• publish

Can perhaps copy the readme over from the archived version

So split those dev dependencies back out, that happened in a recent commit

Necessary subtask: publish all packages maintained by the monorepo
And: revert the change to lerna:publish run script

Reasoning: many of these deps are installed for the underlying codebase, and this is doubling the size requirement of the overlapping deps

This issue provides visibility into Renovate updates and their statuses. Learn more

Rate Limited

These updates are currently rate limited. Click on a checkbox below to force their creation now.

• chore(deps): update dependency eslint-plugin-fp-ts to v0.3.0
• chore(deps): update dependency fast-check to v2.20.0
• chore(deps): update dependency multi-semantic-release to v2.11.0
• chore(deps): update dependency prettier to v2.5.1
• chore(deps): update dependency typescript to v4.5.3
• chore(deps): update typescript-eslint monorepo to v5.6.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• fix(deps): update dependency io-ts to ~2.2.0
• chore(deps): update dependency ava-fast-check to v4
• chore(deps): update dependency eslint to v8
• chore(deps): update dependency eslint-config-prettier to v8
• chore(deps): update dependency eslint-plugin-ava to v13
• chore(deps): update dependency eslint-plugin-prettier to v4
• chore(deps): update dependency lint-staged to v12
• chore(deps): update dependency ts-node to v10
• fix(deps): update dependency execa to v6
• fix(deps): update dependency find-up to v6
• fix(deps): update dependency ts-pattern to v3

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): pin dependencies (@ericcrosson/eslint-config, @ericcrosson/prettier-config, @types/debug, @types/docopt, @types/node, @typescript-eslint/eslint-plugin, @typescript-eslint/parser, ava, ava-fast-check, codecov, commitizen, cz-conventional-changelog, eslint, eslint-config-prettier, eslint-plugin-ava, eslint-plugin-fp-ts, eslint-plugin-json-format, eslint-plugin-prettier, eslint-plugin-security, fast-check, lerna, lint-staged, multi-semantic-release, nyc, patch-semantic-release-npm-for-msr, pre-commit, rimraf, ts-node, typescript)
• chore(deps): update dependency @types/docopt to v0.6.33
• chore(deps): update dependency commitizen to v4.2.4
• chore(deps): update dependency @types/node to v14.18.0
• chore(deps): update node.js to v16.13.1 (node, @types/node)
• Click on this checkbox to rebase all open PRs at once

• Check this box to trigger a request for Renovate to run again on this repository

currently must be path

This is/should be done by the typescript-build-linker

So we support the same format that the TypeScript compiler uses.

Downsides:

• extra package and all the vulns that come with it

Upsides:

• less surprises

so we can tell if renovate breaks any linting