You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was helping @NathanWalker tonight with an issue; and it "appears" tns makes the assumption that if the module is NOT listed in the main package.json file devDependancy; that it is a valid dependency.
However, when dealing with some larger projects a devDependancy will install its own devDependancies; and TNS will see these as "Dependancies" and copy them into /platforms/android/src/main/assets/app/tns_modules/ -- then the gradle builder system will attempt to use them as valid dependancies. In Nathan's case; the tar and tar-pack that are pulled in by the gyp tooling were being copied and attempted to be processed. Which would cause the android tooling to fail with an error that I would bet you that Nathan would tell you is very unhelpful.
I believe this is a flawed assumption to assume anything not listed as a direct "devDependancy" is a valid dependancy. I assume the best way to fix this would be to actually iterate through all the package.json files and make a real dependency tree -- probably cache it in the node_modules (use foldernames and main package.json file as as hash name. I would also probably recommend that you make tns require npm 3 or later so that everything is installed in the node_modules folder rather than in sub-directories of the plugins, as this should make this a lot simpler to manage.
The text was updated successfully, but these errors were encountered:
I was helping @NathanWalker tonight with an issue; and it "appears" tns makes the assumption that if the module is NOT listed in the main package.json file devDependancy; that it is a valid dependency.
However, when dealing with some larger projects a devDependancy will install its own devDependancies; and TNS will see these as "Dependancies" and copy them into
/platforms/android/src/main/assets/app/tns_modules/
-- then the gradle builder system will attempt to use them as valid dependancies. In Nathan's case; the tar and tar-pack that are pulled in by the gyp tooling were being copied and attempted to be processed. Which would cause the android tooling to fail with an error that I would bet you that Nathan would tell you is very unhelpful.I believe this is a flawed assumption to assume anything not listed as a direct "devDependancy" is a valid dependancy. I assume the best way to fix this would be to actually iterate through all the package.json files and make a real dependency tree -- probably cache it in the node_modules (use foldernames and main package.json file as as hash name. I would also probably recommend that you make tns require npm 3 or later so that everything is installed in the node_modules folder rather than in sub-directories of the plugins, as this should make this a lot simpler to manage.
The text was updated successfully, but these errors were encountered: