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

Provide an option to preserve the state of the node_modules when packaging #1684

Closed
3 tasks done
JasonYeMSFT opened this issue Mar 1, 2024 · 2 comments
Closed
3 tasks done
Labels
enhancement Feature request

Comments

@JasonYeMSFT
Copy link

Preflight Checklist

  • I have read the contribution documentation for this project.
  • I agree to follow the code of conduct that this project follows, as appropriate.
  • I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

Our observation indicates that during packaging, electron-packager will check the state of "node_modules/" with the "dependencies" field in the package.json. If the "node_modules/" directory doesn't have a module listed in the dependencies, electron-packager will report an error and fail the packaging. If the "node_modules/" directory contains a module that is not listed in the dependencies, electron-packager will not copy that module to the packaged app. And it seems like electron-packager only checks the top-level dependencies. It doesn't care about sub-dependencies.

Proposed Solution

Add an option in electron-packager to skip checking the dependencies in the package.json and preserve the state of the "node_modules/" directory when packaging the app.

Alternatives Considered

We currently workaround the issue by modifying the dependencies field in package.json prior to packaging, adding the missing ones and removing the bundled ones.

Additional Information

My team ships an electron app that includes a mixture of JavaScript and node native modules. We want to minimize the binary footage of the artifacts we ship so we decided to bundle our JavaScript. We have an algorithm that parses our dependency graph to decide which files are necessary at runtime so we can delete the rest. This results in a mismatch of the state of the "node_modules/" directory and the package.json. We don't want to simply put these packages in devDependencies because we still want to use the two fields to separate packages that are shipped vs. packages that ara only used for development. Allowing the electron-packager to skip the dependency check will save us from doing the package.json manipulation.

@JasonYeMSFT JasonYeMSFT added the enhancement Feature request label Mar 1, 2024
Copy link

welcome bot commented Mar 1, 2024

👋 Thanks for opening your first issue here! If you have a question about using Electron Packager, read the support docs. If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. Development and issue triage is community-driven, so please be patient and we will get back to you as soon as we can.

To help make it easier for us to investigate your issue, please follow the contributing guidelines.

@MarshallOfSound
Copy link
Member

We have an algorithm that parses our dependency graph to decide which files are necessary at runtime so we can delete the rest. This results in a mismatch of the state of the "node_modules/" directory and the package.json. We don't want to simply put these packages in devDependencies because we still want to use the two fields to separate packages that are shipped vs. packages that ara only used for development. Allowing the electron-packager to skip the dependency check will save us from doing the package.json manipulation.

You can either do what you're asking and disable pruning prune: false in packager options. Or change your logic to be more Correct ™️ similar to what forge does which is ignore things via the packager ignore config instead of deleting things before packager gets a go at things.

@MarshallOfSound MarshallOfSound closed this as not planned Won't fix, can't repro, duplicate, stale Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature request
Projects
None yet
Development

No branches or pull requests

2 participants