Skip to content

fix(scripts): make it so prepack runs properly #419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Conversation

zkat
Copy link
Contributor

@zkat zkat commented Apr 1, 2025

Fixes: #257

@zkat zkat requested a review from a team as a code owner April 1, 2025 18:40
@zkat
Copy link
Contributor Author

zkat commented Apr 1, 2025

not sure why, but my tests aren't even passing locally (on main!) so it's hard to figure out what's actually going on here.

@wraithgar
Copy link
Member

is your local fork out of sync? there's a lot of weird diffs here I don't understand.

@zkat
Copy link
Contributor Author

zkat commented Apr 1, 2025

oh, is it? Maybe that's it. One sec.

@zkat
Copy link
Contributor Author

zkat commented Apr 1, 2025

ughhhh I totally messed that up. One sec.

github-actions bot and others added 5 commits April 1, 2025 15:48
🤖 I have created a release *beep* *boop*
---


## [21.0.0](npm/pacote@v20.0.0...v21.0.0)
(2024-11-25)
### ⚠️ BREAKING CHANGES
* `bun.lockb` files are now included in the strict ignore list during
packing
* this module is now compatible with the following node versions:
^20.17.0 || >=22.9.0
### Bug Fixes
*
[`844dc08`](npm@844dc08)
update node engines to ^20.17.0 || >=22.9.0 (npm#414) (@wraithgar)
### Dependencies
*
[`2cb6fa7`](npm@2cb6fa7)
[npm#415](npm#415) `npm-packlist@10.0.0`
(npm#415)
*
[`47b928c`](npm@47b928c)
[npm#412](npm#412) replace node builtin
rmSync with rimraf (npm#412) (@mbtools)
### Chores
*
[`b6f35a2`](npm@b6f35a2)
[npm#402](npm#402) bump @npmcli/arborist
from 7.5.4 to 8.0.0 (npm#402) (@dependabot[bot])
*
[`1ef54ba`](npm@1ef54ba)
[npm#408](npm#408) support tests on win32
(npm#408) (@mbtools)
*
[`555b000`](npm@555b000)
[npm#401](npm#401) bump @npmcli/template-oss
from 4.23.3 to 4.23.4 (npm#401) (@dependabot[bot], @npm-cli-bot)

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
@zkat
Copy link
Contributor Author

zkat commented Apr 1, 2025

alright. I'm not sure what the two test failures are actually about: I've manually tested that this works, and I think I just don't remember how this part of tap works. I guess the test is hanging somehow?

I also have NO idea what the other failure is about. Maybe they're related? Workspaces are just not a thing I ever touched.

@zkat
Copy link
Contributor Author

zkat commented Apr 1, 2025

my access is gonna be cut off any minute now, so is it ok if I just leave this one in your hands? I'm pretty sure it's just about ready to get over the finish line.

Although my brain's been really scrambled today. I might have just COMPLETELY missed the mark. In which case I apologize and please close and ignore. I was just trying to help the TS team with one last thing :)

@@ -54,7 +52,22 @@ class DirFetcher extends Fetcher {
npm_package_json: resolve(this.resolved, 'package.json'),
},
})
})
}
if (process.env._PACOTE_FROM_GIT_ === 'yes' && mani.scripts?.prepack) {
Copy link
Member

Choose a reason for hiding this comment

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

I'm confused why this secret env is needed. These are generally a code smell.

Copy link
Contributor Author

@zkat zkat Apr 2, 2025

Choose a reason for hiding this comment

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

I chose that because it seemed to be the chosen strategy for configuring the underlying NPM subprocess with special behavior when the git fetcher is invoking the dir fetcher (see _PACOTE_NO_PREPARE_). There could be better ways, like checking the spec of the package being built to see if it's a git spec, though. Idk why I didn't think of that.

Copy link
Member

Choose a reason for hiding this comment

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

I'll have to noodle on this. We do know at some point we are from git and could set real state here that's not process.env. Maybe.

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.

[BUG] prepack is not called on installation of git packages
2 participants