Conversation
…ripts and configuration
- Add `get-last-release.js` to determine the last tagged release. - Introduce `get-logger.js` for logging purposes. - Create `get-next-version.js` to calculate the next version based on the last release. - Implement `get-release-to-add.js` to find releases merged from higher branches. - Add `git.js` for Git operations including fetching tags and commits. - Introduce `hide-sensitive.js` to mask sensitive environment variables. - Create `plugins/index.js` to manage plugin loading and configuration. - Implement `plugins/normalize.js` for normalizing plugin options. - Add `plugins/pipeline.js` to execute plugins in a pipeline. - Create `plugins/utils.js` for utility functions related to plugins. - Implement `utils.js` for various utility functions including version handling. - Add `verify.js` to validate the configuration and environment. - Update `package.json` to reflect new structure and dependencies.
…ove linting scripts - Added "types" field to specify TypeScript definitions file. - Updated "exports" to include types alongside the default entry point. - Included "index.d.ts" in the "files" array for distribution. - Added "lint:core" script to run core linting. - Updated "test" script to include a "test:core" alias for consistency.
- Changed the test command to use AVA with verbose output. - Added AVA configuration for test files, node arguments, and timeout. - Updated devDependencies to include AVA version 8.0.1.
…d git helper methods
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub. |
- Introduced a noop plugin for testing purposes. - Added a result configuration plugin to return pluginConfig and context. - Enhanced get-config tests to validate plugin options and context handling. - Created git utility functions for tagging and adding notes. - Implemented extensive tests for plugin normalization, including various input formats and error handling. - Developed pipeline tests to ensure sequential execution of plugin functions with error handling. - Added utility tests for plugin validation and loading mechanisms. - Ensured compatibility with shareable config modules and proper error reporting for invalid plugin configurations.
…ve data, utility functions, and verification logic - Implemented tests for various git operations including fetching, tagging, and branch management in `git.test.js`. - Added tests for hiding sensitive environment variables in `hide-sensitive.test.js`. - Created utility function tests in `utils.test.js` covering version extraction and comparison. - Developed verification tests in `verify.test.js` to ensure proper error handling and validation of branch and tag formats.
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
…mit-analyzer` as default packed plugin
…onfig and related functions
…`default`, `resolveConfig`, `getLogger`, and `resolveEnvCi` functions
… signature, inputs, and return value
I would add a follow up issue with the above checklist as deliverable |
gr2m
left a comment
gr2m
left a comment
There was a problem hiding this comment.
two things I couldn't asses for myself in detail yet but didn't want to block the PR farther, we can do follow ups to investigate
-
options.originalRepositoryURL is undefined for every direct core consumer. index.js:49 logs Run automated release ... on repository ${options.originalRepositoryURL}, but
nothing in core sets that field — upstream set it in the entry point, the wrapper branch sets it manually, and core's own integration test has to set it by hand
(test/integration.test.js:24). Anyone following the README examples gets "on repository undefined". resolveConfig should set it (or run() should capture options.repositoryUrl
before getGitAuthUrl overwrites it with the credential-embedding URL — callers shouldn't need to know this internal detail). -
The output formatter was removed, not injected. formatOutput is a hardcoded identity function, so dry-run release notes and error details (markdown) print raw to the
terminal. Phase 2's "Isolate or inject terminal rendering formatter" is checked, but there's no injection point — and the wrapper can't compensate because core writes to
stdout/stderr itself (the wrapper branch even still carries marked/marked-terminal as now-dead dependencies). The PR's own Phase 4.5 leaves "Accept marked-terminal instance as
args???" unchecked while claiming "IMPERATIVELY 100% backward compatible". Since fixing this later changes core's public API, I'd add the injection point now: accept an
optional formatOutput on the input (defaulting to identity), and have the wrapper pass its marked-terminal renderer.
And a few smanller nits
- Context validation: the default export validates context.options and plugins with clear TypeErrors, but omitting envCi, logger, stdout, or stderr produces destructuring
crashes deep inside run(). Validate the full contract up front — it's literally Phase 2's "fails fast with clear messages" goal. - index.d.ts accuracy: doc comments still claim the default plugins are the four wrapper plugins (stale for core); the plugins input is typed only as Record<string, fn>
although arrays of plugin specs are accepted (that's the headline "direct composition" feature); FailContext.errors shadows the global AggregateError. - Test coverage gaps in this repo: resolve-config.test.js is 147 lines / 5 tests vs upstream's 729-line get-config.test.js — the extends/shareable-config edge cases are
untested here despite the file being modified. And the ~2,000-line behavioral suite for the engine now lives only in the wrapper repo, so core can regress independently of its
own CI. Port these over time. - README nits: getLogger streams are documented as "optional; defaults are process streams" but get-logger.js has no defaults — getLogger({}) produces a broken logger. Also
document explicitly that core does not do CI guards (PR skip, auto dry-run) and does not set GIT_AUTHOR_*/GIT_ASKPASS env vars — callers own those. - package.json hygiene: drop the "start": "node index.js" script (meaningless for a library); the prettier glob "*.{js,json,md}" only checks root-level files, so lib/ and
test/ are unlinted; no eslint despite upstream having lint rules. - Library behavior of hookStd: core always hooks the global process.stdout/process.stderr for sensitive-value masking — defensible, but surprising for an embeddable library;
consider scoping to the provided streams or making it configurable. - The rewritten error-doc links (semantic-release.org/usage/..., /foundation/plugins) all resolve correctly — I spot-checked them.
…pdate plugin types
…tput in semantic-release
…e context branches
|
Addressed the nits except these...
...and...
I'd prefer in a follow-up PR 🤔 |
|
🎉 This PR is included in version 1.0.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
2 participants
Phase 1: Repository and Package Scaffolding
Objective: Introduce package boundaries with minimal behavior change.
Checklist:
packages/core(or equivalent) with package metadata for@semantic-release/core.index.js,lib/, type definitions) into core package structure.Deliverables:
@semantic-release/corepackage in repository.Phase 2: Core Decoupling and Default Behavior Ownership
Objective: Make core fully composable and remove default plugin assumptions from core.
Checklist:
pluginsis empty in core package.analyzeCommits).yargs, CLI-only renderer packages).Deliverables:
Phase 3: Wrapper Package Compatibility Layer (
semantic-release)Objective: Preserve existing user behavior by making
semantic-releasea thin adapter.Checklist:
index.jsto delegate execution to@semantic-release/core.Deliverables:
semantic-releasecommands work with no user config changes.Reference: https://github.com/semantic-release/semantic-release/tree/feat/core-integration
Phase 4: Test Strategy and Regression Hardening
Objective: Prove no regressions in wrapper and expected behavior in core.
Checklist:
@semantic-release/core.Deliverables:
Phase 4.5: Cracking
core😤Objective: Make core composable and IMPERATIVELY 100% backward compactible to
semantic-releaseChecklist:
@semantic-release/commit-analyzeras default core plugin with fallback support - support cases belowanalyzeCommitstep implementation - fallback to core's packed@semantic-release/commit-analyzerpluginscomposition allowing user to pass plugin configuration with plain array object/sting tocorepluginsfield, including ones built from sharable config - making direct composition the most authoritative plugin sourcecoregetConfig- so expose this as an api fromcoresemantic-releasedefault 4 plugins (@semantic-release/commit-analyzer,@semantic-release/release-notes-generator,@semantic-release/npm,@semantic-release/github) regardless ofcorehaving its own 1 default plugin (@semantic-release/commit-analyzer)semantic-releasea wrapper built oncore, allow wrappers the ability to build their own default config/plugins with fallback support tocorecommit analyzer when wrapper's default does not have any plugin that implements theanalyzeCommitsstepcore's packed commit analyzer when wrapper's default or consumer's config does not have any plugin that implements theanalyzeCommitsstepmarked-terminalinstance as args to render terminal markdown???Deliverables
semantic-release/coreinstallable insemantic-releasewith zero breakingPhase 5: Documentation and Migration Guidance
Objective: Make adoption and upgrade path clear.
Checklist:
@semantic-release/coreusage docs with minimal and advanced examples.semantic-releasedocs to explain default behavior remains and where customization lives.Deliverables:
Phase 6: Release and Rollout
Objective: Ship safely with clear communication and rollback options.
Checklist:
@semantic-release/coreinitial version with release notes.semantic-releasewrapper release with explicit compatibility notes.Deliverables:
Related Issue
@semantic-release/corepackage to enable composable release pipelines semantic-release#4072