Skip to content
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

build: Switch from npmignore to files field #9991

Merged
merged 13 commits into from
Jan 2, 2024
Merged

Conversation

lforst
Copy link
Member

@lforst lforst commented Dec 28, 2023

This whole .npmignore mess lead to issues in the past and we wanted to change it since forever so I am using this phase of pondering and loneliness to finally fix it.

Tarball files before (generated with sh scripts/get-files-in-tarballs.sh before.txt): https://gist.github.com/lforst/c74044bcf247125111428d31489b3977

@lforst lforst requested a review from anonrig December 28, 2023 16:57
@lforst lforst marked this pull request as ready for review December 28, 2023 16:57
"cjs",
"esm",
"types",
"types-ts3.8",
Copy link
Contributor

Choose a reason for hiding this comment

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

Astro doesn't have integration and types-ts3.8 on npm. Also I think we should also add README.md files. https://www.npmjs.com/package/@sentry/astro?activeTab=code

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh you're right. I believe we had it at some point, so we probably forgot to remove it previously.

Copy link
Member Author

Choose a reason for hiding this comment

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

We don't need to explicitly add READMEs. They are included by npm by default just like the license and the package json itself: https://docs.npmjs.com/cli/v10/configuring-npm/package-json#files

@lforst lforst requested a review from Lms24 January 2, 2024 09:32
Copy link
Member

@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

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

I really prefer the explicit files array over our current .npmignore approach. Thanks for tackling this! Had a remark but otherwise ready from my PoV!

@@ -17,6 +17,12 @@
"node": ">=18.14.1"
},
"type": "module",
"files": [
"cjs",
Copy link
Member

Choose a reason for hiding this comment

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

m (not just relevant for this file but for all):

Right now, the files array's contents point to paths relative to <package>/build. This conflicts a bit with the entry points semantics where we point to files from <package>. There's good reason for both but we could consider unifying this to <package> to avoid confusion.

WDYT? I don't have a strong opinion that we should do this because I'm well aware of this fact but maybe it'd be worth doing so. The downside is that we need to rewrite the array in prepack.ts just like we do for the entry points.

If our plan is still to remove prepacking, feel free to completely disregard this.

Comment on lines 17 to 19
if (fs.existsSync('.npmignore')) {
ASSETS.push('.npmignore');
}
Copy link
Member

Choose a reason for hiding this comment

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

l: I think we already check for existence further below when copying the assets. Do we need this check here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Down below we check for an asset, but we throw if it doesn't exist. I could switch the logic below to just copy if a file exists and noop otherwise.

Copy link
Member

@Lms24 Lms24 left a comment

Choose a reason for hiding this comment

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

Discussed my previous review offline, all good from my end!

@@ -0,0 +1,46 @@
#!/bin/bash
Copy link
Member

Choose a reason for hiding this comment

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

Maybe stupid question, but where/why are we using this? 😅

Copy link
Member Author

Choose a reason for hiding this comment

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

See the PR description. I was using this to verify that the files in the tarballs were the same before and after my changes. I want to keep this file around because I have a feeling that we are gonna make adjustments to the prepack scripts soon.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, that makes sense, but do we need to check this in here? I'd remove this if we don't need this (regularly)?

Copy link
Member Author

Choose a reason for hiding this comment

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

I can remove it! This PR will persist.

@lforst lforst merged commit ff95fd5 into develop Jan 2, 2024
95 checks passed
@lforst lforst deleted the lforst-rm-rf-npmignore branch January 2, 2024 12:15
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.

4 participants