Update README.md
update the readme to explain how to workaround the limitations (not supporting dynamic require statements and lack of native module support the pseudo support of __dirname)
This commit is contained in:
@@ -20,9 +20,69 @@ Nexe is a command-line utility that compiles your Node.js application into a sin
|
||||
- Linux / Mac / BSD / Windows
|
||||
- Windows: Python 2.6 or 2.7 (in PATH), Visual Studio 2010 or 2012
|
||||
|
||||
## Caveats
|
||||
##Caveats
|
||||
|
||||
- Doesn't support native modules (yet).
|
||||
### Doesn't support native modules
|
||||
|
||||
- Use the techniques below for working around dynamic require statments to exclude the module from the bundling, and deploy along side the executable in a node_module folder so your app can find it.
|
||||
|
||||
###Doesn't support dynamic require statments
|
||||
Such As:
|
||||
```
|
||||
var x = require(someVar);
|
||||
```
|
||||
|
||||
In this case nexe won't bundle the file
|
||||
|
||||
```
|
||||
var x;
|
||||
if (someCheck) {
|
||||
x = require("./ver1.js");
|
||||
}
|
||||
else {
|
||||
x = require("./var2.js");
|
||||
}
|
||||
```
|
||||
|
||||
In this case nexe will bundle both files.
|
||||
|
||||
Workarounds:
|
||||
1) for dyanmic requires that you want bundled add the following into your project
|
||||
```
|
||||
var dummyToForceIncludeForBundle = false;
|
||||
if (dummyToForceIncludeForBundle) {
|
||||
require("./loadedDynamicallyLater.js");
|
||||
...
|
||||
}
|
||||
```
|
||||
this will trick the bundler into including them.
|
||||
|
||||
2) for dynamic files getting included that you don't want to be
|
||||
```
|
||||
var moduleName = "./ver2.js";
|
||||
if (someCheck) {
|
||||
moduleName = "./ver1.js";
|
||||
}
|
||||
var x = require(moduleName)
|
||||
```
|
||||
Note: neither file will be bundled.
|
||||
|
||||
Using these two techniques you can change your application code so mdoules are not bundles, and generate a includes.js file as part of your build process so that the right files get bundled for your build configuration.
|
||||
|
||||
### __dirname
|
||||
|
||||
Once the module is budnled it is part of the executable. __dirname is therefore the CWD (current working dir) of the executable when run. Thus if you put resources on a realtive path from the cwd of the executable (in most cases the path to the executable) your app will be able to access them.
|
||||
|
||||
If you had a data file at /dev/myNodeApp/stateManager/handler/data/some.csv
|
||||
and a file at /dev/myNodeApp/stateManager/handler/loader.js
|
||||
```
|
||||
module.exports = fw.readFileSync(path.join(__dirname, "./data/some.csv"));
|
||||
```
|
||||
you would need to deploy some.csv in a sub dir data/ along side your executable
|
||||
|
||||
There are potential use cases for __dirname where the CWD is not the correct substitution, and could result in a silent error (possibly even in a dependciey that you are unaware of).
|
||||
|
||||
Note: __filename will be 'undefined'
|
||||
|
||||
## Installation
|
||||
|
||||
|
||||
Reference in New Issue
Block a user