yanice: 3.6.0; @yanice/import-boundaries: 1.4.0

Yanice 3.6.0

• Update schema.json to accommodate new options for @yanice/import-boundaries (see below)
• Bumping schema.json-version. This technically constitutes a very small breaking change; the schemaVersion in the schema.json needs to be increased to 3. Unless the new features of @yanice/import-boundaries are used, this can be done without any further change. The reason why this was shipped anyway is to have better error-reporting if the local version of yanice is not up-to-date yet, but the yanice.json already makes use of new features.

@yanice/import-boundaries 1.4.0

• feature: Introduce new rule, no-circular-imports. It disallows any circular imports between any of the files, independent of project-setup.

Full Changelog: v3.5.1...v3.6.0

yanice: 3.5.1

• bugfix: Add new import-rule to enum in schema.json

Full Changelog: v3.5.0...v3.5.1

yanice: 3.5.0; @yanice/import-boundaries: 1.3.0

Yanice 3.5.0

• Update schema.json to accommodate new options for @yanice/import-boundaries (see below)

@yanice/import-boundaries 1.3.0

• feature: Introduce new rule, restrict-package-imports. This allows to limit/constrain imports from 3rd-party-packages on a per-project-basis.

Full Changelog: v3.4.0...v3.5.0

yanice: 3.4.0; @yanice/import-boundaries: 1.2.0

Yanice 3.4.0

• Update README

@yanice/import-boundaries 1.2.0

• bugfix: Ignore files that were deleted from the working tree but still existed in the git-index. This led previously to a crash when attempting to read such a file, as it no longer existed on the file system.
• feature: Also consider aggregated exports such as export * from './some-file' for import-boundaries, as they're implicit imports.

Full Changelog: v3.3.0...v3.4.0

yanice: 3.3.0; @yanice/import-boundaries: 1.1.0

Yanice 3.3.0

• Extend schema.json to accommodate for new options for @yanice/import-boundaries 1.1.0

@yanice/import-boundaries 1.1.0

• Extend access-via-entrypoints-rule: Disallow entrypoint-access from within same project by default. Technically a breaking change but most likely a desired one, as accessing entrypoints from within the same project usually leads to undesired cyclic dependencies. The new errors can however be suppressed using the assertionOptions.accessViaEntryPoints.accessViaEntryPoints-flag in the yanice.json. See README for further details.

yanice: 3.2.0; @yanice/import-boundaries: 1.0.0

yanice v3.2.0

In case you are not using @yanice/import-boundaries, or custom plugins, there should not be any changes. Otherwise, it's mostly changes in the API, the underlying data that is provided should mostly be the same.
Yanice now extensively exports typescript-types which can be used to write type-safe plugins. An example should be linked in the latest README. Keep in mind however that writing the plugin in typescript requires it to be transpiled to commonJS so that yanice can consume it.

Additional features:

• Yanice now supports a third option (apart from pathGlob and pathRegexp) to define a project: projectFolder. Any file that is inside the given folder will be considered part of the project.

@yanice/import-boundaries v1.0.0

The rules have been reworked and provide now much more extensive functionality. In spirit, it still works very similar, however, most APIs had significant breaking changes as a lot has been moved around.

A (probably incomplete) list of breaking changes:

• The configuration-options for the plugin in the yanice.json have been reworked. Most options existing in the past are still supported.
• Instead of traversing the filesystem directly, the plugin now invokes git ls-files to determine which files to consider for import-boundary-assertions. Previously, it was possible to also consider git-ignored files, this is now not supported anymore.
• Performance: Determining which file belongs to which project could become quite inefficient if there were a lot of files/projects available. In case performance is an issue, consider switching to using projectFolder (see yanice-release-notes above). With the aforementioned switch to using git ls-files, this should speed up the process quite a lot.
• Performance: New parameter --perf-log to log some timings.
• // @yanice:import-boundaries ignore-next-statement has been removed, use // @yanice:import-boundaries ignore-next-line instead
• The arguments that can be provided to the plugin have been renamed/reworked. See README for details.
• The structure of the "import-resolution"-map has changed quite drastically. In case you consumed it in e.g. a custom assertion, you might want to look at the newly provided typescript-types that can be consumed to write custom assertions (or consume output for other purposes). See README for details and links.

Some internals:

• Test-coverage is now much more extensive, with a suite of integration-tests that execute yanice directly on a test-project.
• Dogfeeding: Yanice now uses the import-boundaries-package to ensure package-boundaries are honored within the yanice-repository itself

Full Changelog

v3.1.0...v3.2.0

3.1.0

yanice (v3.1.0)

• Remove dependencies: graceful-fs, async. Implement internal promise-queue to achieve this
• Improve logging: Give better information about command-duration and remaining queue-size in run-mode

@yanice/import-boundaries (v0.1.0)

• Do not depend on graceful-fs (via yanice) anymore

Full Changelog

v3.0.2...v3.1.0

3.0.2

yanice (v3.0.2)

• Add dependency: graceful-fs (https://www.npmjs.com/package/graceful-fs)
• Expose file-reader which uses graceful-fs

@yanice/import-boundaries (v0.0.3)

• Use newly exposed file-reader to avoid EMFILE-errors on somewhat large projects (especially on windows)
• Note: This is a workaround. Long-term, we probably want to handle this on our own.

Full Changelog

v3.0.1...v3.0.2

3.0.1

yanice (v3.0.1)

• Very tiny performance improvement (avoid some unnecessary glob/regex-checks)

@yanice/import-boundaries (v0.0.2)

• Add new assertion-rule; max-skipped-imports

Full Changelog

v3.0.0...v3.0.1

3.0.0

New feature: Plugins!

Yanice now supports plugins. In their current form, plugins can take all the data that yanice calculates and do whatever with them. Currently, there's one officially supported plugin: @yanice/import-boundaries. See here for details: README.md. Custom plugins are also possible.

Breaking Changes

To enable plugins, the CLI-api had to be changed.
The first parameter is now not scope anymore, but run|output-only|visualize|plugin:<plugin-name>. Related flags like --visualize, --output-only etc. have been removed.

Old:

npm run yanice -- lint --concurrency=4 --rev=HEAD

New:

npm run yanice -- run lint --concurrency=4 --rev=HEAD

Changelog

All changes: v2.6.0...v3.0.0