-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Do not rely on package.json and package-lock.json #19373
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
Closed
Closed
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
6dfc5ee
Import acorn in tools/acorn-optimizer.js directly instead of relying …
juj 6b6a095
Remove package.json and package-lock.json when running tests. XXX do …
juj 39a154f
Move package.json away, then restore it, to avoid dirty git failing t…
juj d2b3a55
Add recursion guard
juj 1cfb18e
Delete all package.json files, not just the one in root
juj fc496a3
Flake
juj File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that idea here is that you want to remove the package.json file from your distribution of emscripten?
Could you avoid this change by instead just emptying it out? i.e. remove all the deps from it, but have it still be there to act as root so that that our
node_modules
can be located?Perhaps we should do the same thing for emsdk, so that we know we have good test coverage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I want to delete the package.json file in our Unity redistribution, at the root, or possibly even recursively in all subdirectories. Looks like the CI run came back green for when one would just delete the root package.json files, so that seems functionally safe thing to do, if we only change this one line.
I would prefer to change the acorn lookup here to be manual so we don't need to rely on package.json at all, since otherwise I would need to maintain stub package.jsons in our redistributable creator script. Manual lookup here does not look so bad, as terser already is being manually found as well anyways? (on the next line)
I am not proposing that package.jsons would (necessarily) be deleted from the emscripten installations that google's waterfall does, but that the test runs that we are running on Emscripten CircleCI would always run in this mode where these package.json files (either at root, or recursively) are deleted, so that we know that running in this mode will remain safe thing for us to rely on. (I don't anticipate that we would evolve any features that would actually need these)
Hmm, emsdk does not use node_modules/package.json, or maybe I misunderstood here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think both unity's distribution and emsdk's distribution expect
node_modules
to be pre-existing and don't expect to ever runnpm
to add/remove/update stuff.So in both/all cases I think we can strip the
package.json
file when we ship.I would rather ship an empty one so that we can avoid absolute paths.. but maybe there is some other way do that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also this whole thing strikes me as rather crazy.. since we not actually removing any of the insecure code, just making a little harder for the security scanners to find it :-/ I'm not sure that's a good direction to go in.