Skip to content

Remove fs-extra#1476

Merged
Andarist merged 20 commits intochangesets:nextfrom
pralkarz:remove-fs-extra
Oct 5, 2024
Merged

Remove fs-extra#1476
Andarist merged 20 commits intochangesets:nextfrom
pralkarz:remove-fs-extra

Conversation

@pralkarz
Copy link
Copy Markdown

@pralkarz pralkarz commented Oct 3, 2024

Part of the v3 cleanup: #1473. fs-extra is effectively unnecessary in modern Node versions, and can be replaced with the native functionality.

@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Oct 3, 2024

🦋 Changeset detected

Latest commit: 4b54c84

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 10 packages
Name Type
@changesets/apply-release-plan Patch
@changesets/release-utils Patch
@changesets/test-utils Patch
@changesets/config Patch
@changesets/write Patch
@changesets/read Patch
@changesets/cli Patch
@changesets/git Patch
@changesets/pre Patch
@changesets/get-release-plan Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@codecov
Copy link
Copy Markdown

codecov Bot commented Oct 3, 2024

Codecov Report

Attention: Patch coverage is 79.66102% with 12 lines in your changes missing coverage. Please review.

Please upload report for BASE (next@ac917ca). Learn more about missing BASE report.

Files with missing lines Patch % Lines
packages/apply-release-plan/src/index.ts 80.95% 4 Missing ⚠️
packages/git/src/index.ts 0.00% 4 Missing ⚠️
packages/cli/src/run.ts 40.00% 3 Missing ⚠️
packages/cli/src/commands/init/index.ts 87.50% 1 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##             next    #1476   +/-   ##
=======================================
  Coverage        ?   81.01%           
=======================================
  Files           ?       54           
  Lines           ?     2239           
  Branches        ?      657           
=======================================
  Hits            ?     1814           
  Misses          ?      421           
  Partials        ?        4           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Comment thread packages/apply-release-plan/src/index.test.ts Outdated

afterEach(() => {
console.error = consoleError;
jest.restoreAllMocks();
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some tests were failing without this when run as a suite, but passed individually. Not sure why.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, interesting - i'll take a look into this before landing htis

Comment on lines +2967 to +2969
let pathExists = await access(changesetPath)
.then(() => true)
.catch(() => false);
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, could be a common utility function somewhere. This implementation is also what fs-extra.pathExists is doing under the hood, so we might need to credit the author here? Not sure since even Node documentation suggests using access for asynchronous existence checks.

This is needed due to a conflict with Node types that was fixed
in 2.3.4. Also dedupes the dependency, so overall a net positive.
See: https://github.com/enquirer/enquirer/blob/master/CHANGELOG.md#234---2020-01-13
@bluwy
Copy link
Copy Markdown
Member

bluwy commented Oct 4, 2024

This looks great to me too. I don't know what others think, but I usually prefer import fs from 'node:fs/promises rather than named imports because the API surface is large and names can likely collide or misinterpreted as custom functions. But I don't think it's a big deal if others are fine by the named imports too.

For the access/then/catch pattern, I wonder if it's also fine to simply use fsSync.existsSync. It's not exactly the same as access also checks for file permissions rather than just existing, but I don't know if it'd matter in most case. But again also not a big deal for me 😄

@pralkarz
Copy link
Copy Markdown
Author

pralkarz commented Oct 4, 2024

This looks great to me too. I don't know what others think, but I usually prefer import fs from 'node:fs/promises rather than named imports because the API surface is large and names can likely collide or misinterpreted as custom functions. But I don't think it's a big deal if others are fine by the named imports too.

For the access/then/catch pattern, I wonder if it's also fine to simply use fsSync.existsSync. It's not exactly the same as access also checks for file permissions rather than just existing, but I don't know if it'd matter in most case. But again also not a big deal for me 😄

I'm fine with changing to default imports as my preference for named imports is very shallow, as in I can't even quite put my finger on why I prefer them. I'm gonna hold off on making the change for now though, in case someone with a stronger opinion pops in! 😄

As for existsSync, that's what I've usually ended up doing in other projects where I've worked on removing fs-extra, but I usually try to keep the behavior as close to the original fs-extra usage as possible on the first pass, and then make the change if the maintainers are fine with it.

@Andarist
Copy link
Copy Markdown
Member

Andarist commented Oct 4, 2024

i softly prefer dotted access to those but it's harder to set up autoimports for that than for named exports so 🤷

@Andarist
Copy link
Copy Markdown
Member

Andarist commented Oct 4, 2024

@ziebam could you add a changeset to this PR?

@pralkarz
Copy link
Copy Markdown
Author

pralkarz commented Oct 4, 2024

@ziebam could you add a changeset to this PR?

I initially branched off off main (the next branch didn't exist yet), and later caught up with next manually, so now I get this error:

$ packages/cli/bin.js
🦋  error Error: Failed to find where HEAD diverged from next. Does next exist?
🦋  error     at getDivergedCommit (/home/pralky/dev/changesets/packages/git/src/index.ts:51:11)
🦋  error     at getChangedFilesSince (/home/pralky/dev/changesets/packages/git/src/index.ts:196:22)
🦋  error     at getChangedPackagesSinceRef (/home/pralky/dev/changesets/packages/git/src/index.ts:258:24)
🦋  error     at getVersionableChangedPackages (/home/pralky/dev/changesets/packages/cli/src/utils/versionablePackages.ts:15:27)
🦋  error     at add (/home/pralky/dev/changesets/packages/cli/src/commands/add/index.ts:47:7)
🦋  error     at run (/home/pralky/dev/changesets/packages/cli/src/run.ts:72:5)

Should I temporarily change the "baseBranch" in the config to main to solve this? Also, do I just do the regular patch bump in this case? Not sure what's the correct approach here since this is technically working towards a new major release.

@Andarist
Copy link
Copy Markdown
Member

Andarist commented Oct 4, 2024

Hm, it might be worth investigating why this happens because it's not a good experience for the users. I'll try to repro it later using this branch. To recheck a thing - do you have a next branch locally? What is its tip, is it ac917ca?

Also, do I just do the regular patch bump in this case? Not sure what's the correct approach here since this is technically working towards a new major release.

I'd use patch since it's not a significant change and we want it to be listed in the patch section of changes in the final v3 release

@pralkarz
Copy link
Copy Markdown
Author

pralkarz commented Oct 4, 2024

Hm, it might be worth investigating why this happens because it's not a good experience for the users. I'll try to repro it later using this branch. To recheck a thing - do you have a next branch locally? What is its tip, is it ac917ca?

Also, do I just do the regular patch bump in this case? Not sure what's the correct approach here since this is technically working towards a new major release.

I'd use patch since it's not a significant change and we want it to be listed in the patch section of changes in the final v3 release

I thought I had (I pulled the refs earlier), but I had to actually checkout next and then back to my branch to get it to work. Seems like a mistake on my part then.

@Andarist
Copy link
Copy Markdown
Member

Andarist commented Oct 4, 2024

I'm glad that you have resolved the issue. I think this could be improved in the tool though - likely we don't consult the remote at all in this kind of a situation, the local branch could also be outdated. It might be worth rechecking how Changesets behave in cases like this.

@pralkarz
Copy link
Copy Markdown
Author

pralkarz commented Oct 4, 2024

I'm glad that you have resolved the issue. I think this could be improved in the tool though - likely we don't consult the remote at all in this kind of a situation, the local branch could also be outdated. It might be worth rechecking how Changesets behave in cases like this.

Indeed. Should I file an issue for that or would you prefer to have it in the v3 discussion?

Related: pushed the changeset and changed the named imports to default ones per your and @bluwy's suggestions.

@Andarist
Copy link
Copy Markdown
Member

Andarist commented Oct 4, 2024

Should I file an issue for that or would you prefer to have it in the v3 discussion?

Let's keep it in that v3 discussion for now.

Copy link
Copy Markdown
Member

@bluwy bluwy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! I think the fs.access thing is probably worth revisiting, but we could do that later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants