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

Dynamic requirements fail #48

Closed
5punk opened this issue Sep 20, 2016 · 5 comments
Closed

Dynamic requirements fail #48

5punk opened this issue Sep 20, 2016 · 5 comments

Comments

@5punk
Copy link

5punk commented Sep 20, 2016

First of all, love your module. It's nice and robust, has made our lives easier.

We are trying to package our app in a node binary, saw users can use it without node. Unfortunately due the dynamic requires in your app, the trash functionality doesn't work.
When we bundle our code for production, it gets built to a binary.

Here: https://github.com/sindresorhus/trash/blob/master/index.js#L22-L24
Here: https://github.com/sindresorhus/trash/blob/master/lib/macos.js#L10
etc.

https://github.com/jaredallard/nexe#doesnt-support-dynamic-require-statements

Can you add the source code as part of the package so it can support compiled binaries?

Thanks.

@sindresorhus
Copy link
Owner

sindresorhus commented Sep 22, 2016

Here: https://github.com/sindresorhus/trash/blob/master/lib/macos.js#L10

What do you want done here?

@5punk
Copy link
Author

5punk commented Sep 22, 2016

@sindresorhus By any chance would you have the source code to that binary?

One of the ways we handle external file requirements is

  • Check if file exists in path
  • If not, write file to path

Then, external file requirements / executions will work :)

@sindresorhus
Copy link
Owner

By any chance would you have the source code to that binary?

Yes, it's linked to from the readme: https://github.com/sindresorhus/macos-trash

One of the ways we handle external file requirements is
Check if file exists in path
If not, write file to path

Please clarify. I have no idea what this means.

@5punk
Copy link
Author

5punk commented Sep 22, 2016

When this package is a dependency to a project that is built into a binary,
__dirname is built into /Users/5punk/projects/ProjectTest/node_modules/trash/bin/macos-trash

So when I give this built binary package to you, macos-trash is not found because it is still trying to search for the binary at /Users/5punk/projects/ProjectTest/node_modules/trash/bin/macos-trash

So a workaround is to check if the file exists in a generic path, if it doesn't exist, write the source code to the generic path.

const BINARY_PATH = isWindows ? '\AppData\trash\macos-trash' : '/opt/trash/macos-trash';

if (!fileExists(path.resolve(BINARY_PATH)) {
  fs.writeFileSync(BINARY_PATH, TRASH_SOURCE_CODE.toString());
  // make it or built it next (clang)
}

// Now feel free to use it :)
var bin = BINARY_PATH;

better yet, just download the release package (.zip) from
https://github.com/sindresorhus/recycle-bin/
https://github.com/sindresorhus/macos-trash

and then, run the build script and now you've binaries at the location you want. :)

@sindresorhus
Copy link
Owner

sindresorhus commented Sep 22, 2016

I'm willing to move the require statements to the top as that's a better practice anyways, but I'm not interested in adding lots of workarounds for this. nexe should just do what Electron does and monkeypatch fs and child_process so it just works transparently: https://github.com/electron/electron/blob/master/docs/tutorial/application-packaging.md#node-api

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

No branches or pull requests

2 participants