feat(esm): convert to esm #2569

travi · 2022-09-23T18:42:43Z

for #2543

outstanding todos

config loading support for some combination of cjs, esm, json, etc
plugin loading support for cjs
plugin loading support for esm
stubbing of env-ci (currently cjs only, which doesnt seem to work with replaceESM)
- feat: convert to native ES Module env-ci#236
stubbing of other cjs-only dependencies (which ones exist?)
integration.test.js

breaking changes

ESM only
references to plugin files in configs need to include the file extension because of executing in an ESM context

for #2543

… into travi/esm

…-only

…bleeding between tests we should try to adjust the stub setup in each test to try to avoid the need for this, but i think that should be tackled separately from the current esm effort for #2543

travi · 2022-10-07T21:32:29Z

test/branches/branches.test.js

+  td.reset();
+});
+
+test.serial('Enforce ranges with branching release workflow', async (t) => {


i dont like making these tests run serially, but it was necessary to avoid conflicts for stub setup between tests in this file when the tests execute in parallel. i think we could rework the stub setup between tests to avoid that situation, but i think that should be given attention separately from the ESM effort

i think the implementation should support loading of esm plugins as well, but we should add test coverage for those scenarios as a follow up for #2543

for #2543

travi · 2022-10-07T22:16:00Z

test/plugins/plugins.test.js

-        verifyConditions: ['./test/fixtures/plugin-noop', {path: './test/fixtures/plugin-noop'}],
-        generateNotes: './test/fixtures/plugin-noop',
-        analyzeCommits: {path: './test/fixtures/plugin-noop'},
+        verifyConditions: ['./test/fixtures/plugin-noop.cjs', {path: './test/fixtures/plugin-noop.cjs'}],


we should probably make sure to mention in the release notes the need to include the extension when referencing plugin files since semantic-release will now execute in an ESM context.

this isnt captured in a breaking change note in the commits, so we may need to modify the generated release notes to account for this

i did end up capturing this in 1e424a0 (#2569) in case we happen to merge this without squashing, but i also started a list in the PR description to capture breaking changes assuming that we do squash

…malization BREAKING CHANGE: since semantic-release now executes in an ESM context, the file extension is required when referencing plugin files for #2543

for #2543

travi · 2022-10-14T04:15:09Z

i did get the majority of the integration tests passing, which gives me more confidence that there are fewer problems than the unit test progress has been suggesting

for #2543

since loading json config cannot be accomplished with import without import assertions for #2543

travi · 2022-11-04T22:07:17Z

test/get-config.test.js

 });

-test('Read options from .releaserc.yml', async (t) => {
+test.serial('Read options from .releaserc.yml', async (t) => {


this file required .serial for some tests due to similar reasons as other test files because of conflicting stub setup with the plugins module

travi · 2022-11-04T22:09:29Z

lib/get-config.js

@@ -25,11 +33,12 @@ module.exports = async (context, cliOptions) => {
  if (extendPaths) {
    // If `extends` is defined, load and merge each shareable config with `options`
    options = {
-      ...castArray(extendPaths).reduce((result, extendPath) => {
+      ...castArray(extendPaths).reduce(async(eventualResult, extendPath) => {
+        const result = await eventualResult;
        const extendsOptions = require(resolveFrom.silent(__dirname, extendPath) || resolveFrom(cwd, extendPath));


switched back to loading config with require instead of import because of the need to load .json files for config, which isnt possible with import unless import assertions are used. since we are planning to raise the required node version to v18, import assertions should be available, but would require knowing the format of the config file before loading it. might be worth considering, but skipping for now

travi · 2022-11-05T02:09:14Z

test/get-config.test.js

+import {gitAddConfig, gitCommits, gitRepo, gitShallowClone, gitTagVersion} from './helpers/git-utils.js';
+
+const {outputJson, writeFile} = fsExtra;
+const pluginsConfig = {foo: 'bar', baz: 'qux'};


i'm interested in thoughts on meaningless data to be returned from a stub. it is meaningless here because the actual value of the data does not matter in any of the uses. it only matters that what is returned from the stub matches the portion of the return value of the called function that is expected.

i normally use a random data generator, like https://github.com/travi/any, for cases like this so that it is clear that the data is meaningless. i find that it also makes it more clear when certain bits of data are important for the behavior of the test, such as the specific attribute that causes a test to execute a particular conditional path. however, doing that here would be inconsistent with the rest of the project (and i want to avoid broader changes like using such an approach somewhat consistently).

i'm interested in opinions on techniques that make sense in this project for meaningless data like this. if longer term thoughts are different than short term thoughts, i'm interested in those as well, even though we'd avoid big changes at this point.

I'd avoid using foo/bar, I'd use something more descriptive.

I see the point for using random data, but I'm not sure if the added complexity is worth it? I'd read the code and wonder why we are setting mock data randomly? But you clearly thought more about it than I did, do what you think is best

for #2543

travi · 2022-11-06T16:51:58Z

the next step here, getting the tests in test/index.test.js passing, will be complicated. the behavior of these tests is driven by the return value from env-ci. currently, the use of td.replaceEsm is failing to stub env-ci, resulting in the return value from the call to env-ci in lib/index.js being undefined.

from experience, td.replaceEsm can only successfully replace a module when it is esm. this is why we took the step to make env-ci esm-only in semantic-release/env-ci#236. however, even though this project's direct dependency on env-ci has been updated use the esm version, the fact that the official plugins used by core define a peer dependency on core and that is satisfied by the current stable version of core, the older version of env-ci is pulled in through that peer dependency. testdouble does not follow the node resolution algorithm, so the fact that there are two versions of env-ci in the dependency tree confuses the stubbing, resulting in the attempt to stub the cjs version instead of the esm version.

$ npm ls env-ci
semantic-release@0.0.0-development /path/to/project/semantic-release/semantic-release
├─┬ @semantic-release/commit-analyzer@9.0.2
│ └─┬ semantic-release@19.0.3
│   └── env-ci@5.5.0
└── env-ci@8.0.0-beta.1

that listing is incomplete, because each of the plugins introduce the same situation:

$ npm ls semantic-release
semantic-release@0.0.0-development /path/toproject/semantic-release/semantic-release
├─┬ @semantic-release/commit-analyzer@9.0.2
│ └── semantic-release@19.0.3
├─┬ @semantic-release/github@8.0.0
│ └── semantic-release@19.0.3 deduped
├─┬ @semantic-release/npm@9.0.0
│ └── semantic-release@19.0.3 deduped
└─┬ @semantic-release/release-notes-generator@10.0.0
  └── semantic-release@19.0.3 deduped

we will need to publish a version (a pre-release for now) of core with the updated env-ci dependency defined, so that the plugins can use that pre-release version, allowing deduplication of the env-ci dependency and enabling testdouble to replace the module as desired.

unfortunately, that likely still won't be enough because of how npm treats pre-releases when satisfying the dependency range. because we have the peer dependency defined with an open-ended upper bound, like https://github.com/semantic-release/commit-analyzer/blob/9b526d1529d7b4763db798f1da2d3659a23c5a5d/package.json#L73, it would be reasonable to assume that the pre-release mentioned above would be enough to enable the desired deduping within the core project. unfortuntely, npm considers a pre-release version as not satisfying a semver range unless the defined range explicitly includes pre-releases within the intended major. i believe we will need to update the plugins to explicitly allow || <next-major>-<pre-release>.

working through these steps will be complicated, but doable.

… into travi/esm

travi · 2022-11-09T16:39:07Z

i retargeted this PR at the beta branch instead of master so that we can publish a pre-release based on the above comment. we would have wanted to pre-release these changes anyway, but in this case we want to pre-release before getting all of the tests passing in order to enable the dance that will allow us to get the rest passing.

github-actions · 2022-11-11T15:26:07Z

:tada: This PR is included in version 20.0.0-beta.1 :tada:

The release is available on:

Your semantic-release bot 📦🚀

github-actions · 2023-01-06T19:56:43Z

:tada: This PR is included in version 20.0.0 :tada:

The release is available on:

Your semantic-release bot 📦🚀

travi added 12 commits August 27, 2022 00:20

wip(esm): initial module type conversion

21a7b60

for #2543

wip(esm): updated dynamic imports in tests and updated testdouble stubs

38ac59d

for #2543

wip(esm): updated the cli module

2736244

for #2543

Merge branch 'master' of github.com:semantic-release/semantic-release…

23862f7

… into travi/esm

fix(cli): imported debug properly

7532da6

fix(dependencies): upgraded most of the dependencies that are now esm…

1303626

…-only

fix(tempy): upgraded to the esm version

c3d0d4e

fix(aggregate-error): accounted for .errors when extracting errors

e572643

test(aggregate-error): accounted for .errors for plugins

43adf8b

test(aggregate-error): accounted for .errors for config verification

6e8863d

chore(ava): upgraded to the latest version

00683dc

test(branches): made the tests run serially since the stub setup was …

56a6679

…bleeding between tests we should try to adjust the stub setup in each test to try to avoid the need for this, but i think that should be tackled separately from the current esm effort for #2543

travi commented Oct 7, 2022

View reviewed changes

test(plugins): focused plugin loading on cjs plugins for the time being

f27131b

i think the implementation should support loading of esm plugins as well, but we should add test coverage for those scenarios as a follow up for #2543

travi force-pushed the travi/esm branch from 291eaf8 to f27131b Compare October 7, 2022 21:54

fix(env-ci): upgraded to the ESM-only beta version of env-ci

5b064cd

for #2543

travi commented Oct 7, 2022

View reviewed changes

travi added 2 commits October 7, 2022 17:24

test(plugins): referenced plugins with extension in the tests for nor…

1e424a0

…malization BREAKING CHANGE: since semantic-release now executes in an ESM context, the file extension is required when referencing plugin files for #2543

refactor(bin): updated the binary file to esm

0a14f4f

for #2543

travi added 2 commits November 4, 2022 16:56

test(get-config): fixed stubbing of the plugins module

6005f8c

for #2543

fix(get-config): loaded config with require rather than import

75c6750

since loading json config cannot be accomplished with import without import assertions for #2543

travi force-pushed the travi/esm branch from 58c6462 to 75c6750 Compare November 4, 2022 22:05

travi commented Nov 4, 2022

View reviewed changes

travi commented Nov 5, 2022

View reviewed changes

travi added 2 commits November 4, 2022 22:29

fix(get-config): awaited the the loading of extended config

0739d7d

for #2543

docs(contributors): added myself to the contributors list

9ab2669

Merge branch 'master' of github.com:semantic-release/semantic-release…

e53693b

… into travi/esm

travi changed the base branch from master to beta November 9, 2022 16:36

travi marked this pull request as ready for review November 9, 2022 16:36

gr2m approved these changes Nov 10, 2022

View reviewed changes

travi merged commit 9eab1ad into beta Nov 11, 2022
2 of 6 checks passed

travi deleted the travi/esm branch November 11, 2022 15:24

github-actions bot added the released on @beta label Nov 11, 2022

github-actions bot added the released label Jan 6, 2023

pdecat mentioned this pull request May 3, 2023

Feat: Support for New Semantic Release Version. pmowrer/semantic-release-monorepo#137

Open

travi mentioned this pull request Nov 1, 2023

Support extending ESM based configurations #3037

Merged

feat(esm): convert to esm #2569

feat(esm): convert to esm #2569

travi commented Sep 23, 2022 •

edited

travi Oct 7, 2022

travi Oct 7, 2022

travi Oct 7, 2022

travi commented Oct 14, 2022

travi Nov 4, 2022

travi Nov 4, 2022

travi Nov 5, 2022

gr2m Nov 7, 2022

travi commented Nov 6, 2022

travi commented Nov 9, 2022

github-actions bot commented Nov 11, 2022

github-actions bot commented Jan 6, 2023

feat(esm): convert to esm #2569

feat(esm): convert to esm #2569

Conversation

travi commented Sep 23, 2022 • edited

outstanding todos

breaking changes

travi Oct 7, 2022

Choose a reason for hiding this comment

travi Oct 7, 2022

Choose a reason for hiding this comment

travi Oct 7, 2022

Choose a reason for hiding this comment

travi commented Oct 14, 2022

travi Nov 4, 2022

Choose a reason for hiding this comment

travi Nov 4, 2022

Choose a reason for hiding this comment

travi Nov 5, 2022

Choose a reason for hiding this comment

gr2m Nov 7, 2022

Choose a reason for hiding this comment

travi commented Nov 6, 2022

travi commented Nov 9, 2022

github-actions bot commented Nov 11, 2022

github-actions bot commented Jan 6, 2023

travi commented Sep 23, 2022 •

edited