Open agonper opened 2 years ago
Hi @agonper, I have exactly the same problem when building a plugin using tns build plugin
. I don't think it's targetSdk 32
related though, I have the same thing with 31.
I discovered that the only way to tell NS where to look for package.json
is to switch to nativescript.config.ts
file where you can override the location of the app directory.
import { NativeScriptConfig } from '@nativescript/core';
export default {
id: 'org.nativescript.app',
appPath: '.',
appResourcesPath: 'App_Resources',
android: {
v8Flags: '--expose_gc',
markingMode: 'none',
},
cli: {
packageManager: "npm",
/**
* Optional - Override the files or paths to clean when running the `ns clean` command
*/
pathsToClean: ["node_modules"],
/**
* Optional - Additional files or paths to clean when running the `ns clean` command, the paths are appended to the
* default list of paths.
*/
additionalPathsToClean: [],
},
useLegacyWorkflow: false,
} as NativeScriptConfig;
This should fix that particular error Error: ENOENT: no such file or directory, open '***/app/package.json'
. But then I am getting this weird SIGINT error, exactly the same as https://github.com/NativeScript/nativescript-cli/issues/5186 which is an old issue but
It appears that this is not just plugin build
command related when I run:
tns info --log trace
The SIGINT part is unrelated - that's normal - it doesn't indicate a failure
Trying to handle SIGINT event. CLI overrides this behavior and does not allow handling SIGINT as this causes issues with Ctrl + C in terminal.
The stackTrace of the location trying to handle SIGINT is:
at process.on (/usr/local/lib/node_modules/nativescript/lib/nativescript-cli.js:26:28)
at /usr/local/lib/node_modules/nativescript/node_modules/signal-exit/index.js:158:17
at Array.filter (<anonymous>)
at load (/usr/local/lib/node_modules/nativescript/node_modules/signal-exit/index.js:156:23)
at module.exports (/usr/local/lib/node_modules/nativescript/node_modules/signal-exit/index.js:62:7)
at Object.<anonymous> (/usr/local/lib/node_modules/nativescript/node_modules/proper-lockfile/lib/lockfile.js:331:1)
at Module._compile (node:internal/modules/cjs/loader:1105:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
The SIGINT part is unrelated - that's normal - it doesn't indicate a failure
Well it clearly crashes plugin build and that's the only error in the detailed logs, so something must be related.
The normal tns plugin build
run without --log trace
does not make sense at all:
FAILURE: Build failed with an exception.
* Where:
Build file '/private/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022328-1547-ga7cpq.a5i7v/***/build.gradle' line: 38
* What went wrong:
A problem occurred evaluating root project '***'.
> /private/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/platforms/android/dependencies.json (No such file or directory)
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 587ms
Failed to build plugin ***:
Error: Command ./gradlew failed with exit code 1
Could it be somehow related to https://github.com/NativeScript/nativescript-cli/issues/5664? - I just noticed that compileSdk version is 32 even thought I have it set to 31 in the build.gradle
file:
spawn: /var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022328-2849-1jj9zr7.ivl7/***/gradlew
"-p"
"/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022328-2849-1jj9zr7.ivl7/***"
"assembleRelease"
"-PcompileSdk=android-32"
"-PbuildToolsVersion=31.0.0"
"-PappPath=/plugin/src"
"-PappResourcesPath=/plugin/src/App_Resources"
So my initial comment that it might not be related to SDK 32 could be wrong... No idea at this point.
The build fails on the gradle side, why it does - I'm not sure yet, haven't had a chance to dig deeper myself. Just thought I'd chime in on the SIGINT part to avoid going down that path, as it is definitely not the cause of the failure.
Ahm, ok, thanks for clarifying.
Is there a way to get a hold of that gradlew:assembleRelease
task trace? I asked about it once on Discord, but the only known detailed log output command I know of is --log trace
.
Annoyingly enough, this file gets wiped out as soon as process exits, so I have no chance of looking into that file and see what's happening on line 38 - but it must be something generic as @agonper has the same line error.
Build file '/private/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022328-1547-ga7cpq.a5i7v/***/build.gradle' line: 38
Got gradle versions {"gradleVersion":"7.4","gradleAndroidPluginVersion":"7.1.2"} from the latest runtime v8.2.2
Project dir from hooksArgs is: undefined.
Hooks directories: [ '/plugin/src/hooks' ]
You have both a nativescript.config.js and nativescript.config.ts file. Defaulting to nativescript.config.ts.
BeforeHookName for command buildAndroidPlugin is before-buildAndroidPlugin
You have both a nativescript.config.js and nativescript.config.ts file. Defaulting to nativescript.config.ts.
Selected targetSdk is: 32
Installed Android Targets are: [ 'android-30', 'android-31', 'android-32' ]
Selected buildToolsVersion is: 31.0.0
spawn: /var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022328-2849-1jj9zr7.ivl7/***/gradlew
"-p"
"/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022328-2849-1jj9zr7.ivl7/***"
"assembleRelease"
"-PcompileSdk=android-32"
"-PbuildToolsVersion=31.0.0"
"-PappPath=/plugin/src"
"-PappResourcesPath=/plugin/src/App_Resources"
> Task :plugin:build FAILED
@rigor789 an update regarding this one.
The big problem that I was finding very annoying up until now was the fact that the temp directory from where the error is thrown was being deleted immediately. So I was not able to go back and inspect the project or look at what's wrong at the reported line Build file '/private/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project***/build.gradle' line: 38
.
Fortunately, I've managed to by watching the directory and copying everything recursively obtain a copy of the project that is generated. Below is the command that is being executed:
spawn:
/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022829-41426-19roham.spy4/my_project/gradlew
"-p"
"/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022829-41426-19roham.spy4/my_project"
"assembleRelease"
"-PcompileSdk=android-32"
"-PbuildToolsVersion=32.0.0"
"-PappPath=/Users/.../my_projectt/plugin/src"
"-PappResourcesPath=/Users/george/.../my_project/plugin/src/App_Resources"
And this is the error being produced by the command:
FAILURE: Build failed with an exception.
* Where:
Build file '/private/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/
android-project2022829-41426-19roham.spy4/my_project/build.gradle' line: 38
* What went wrong:
A problem occurred evaluating root project 'my_project'.
> /private/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/platforms/android/dependencies.json (No such file or directory)
So here is the line 38 from the generated android-project2022829-41426-19roham.spy4
s build.gradle
file, that is going crazy:
We are clearly looking for this /platforms/android/dependencies.json
which is not there.
Notice the path where we are looking for it /private/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/
, it's in a completely different location than generated project folder, which is located at: /private/var/folders/p4/sl5tq_l94y30x3sr7t82kqdh0000gn/T/android-project2022829-41426-19roham.spy4/my_project
.
When or by which task this file is being generated?
Found the template in the source code as well: https://github.com/NativeScript/nativescript-cli/blob/a11cace045856499a44637cd3052501ef34b5757/vendor/gradle-plugin/build.gradle#L32-L38
I am experiencing exactly the same issue.
I use macOS and I am also seeing what appears to be the missing ".../T/..." in the path to the missing "dependencies.json" file referenced in the build error output (as nicely detailed by @grigala in the Sep 29 post above). This leads me to believe the error is more about "no such directory" than it is about "no such file", as I have added a "dependencies.json" file to my plugin project (containing only an empty JSON array "[]"), but I continue to receive the same error.
@agonper / @grigala - did you discover a solution - or a workaround - to this issue?
If so, posting an update would be greatly appreciated! Thank you.
Hi @grfalk, adding an empty dependencies.json
to your project would not change much. I wish it was that easy.
So, after my last discussion with the core members, they all admitted that it's clearly a bug they've introduced, but they've all been surprised that we are still using this way of building plugins, which apparently is considered kind of "legacy" way of doing it (broken legacy way), and they themselves haven't been doing it in this way for a long time. Instead, they are using NX workspace way, like packing the sources directly.
As I didn't get much of an additional feedback, I gave up on it and all my plugins are simply frozen where they were. Migrating to their proposed "just pack sources" isn't trivial and would require quite an effort in my case due to a lot of complexity in my plugins, but maybe it could work fine in your case - give it a go.
@grigala - thank you very much for your reply. It explains a lot regarding what I have been experiencing regarding this error, as well what I am seeing when reviewing {N} tooling source code.
So, based on the feedback you received the {N} core team members...
...they all admitted that it's clearly a bug they've introduced, but they've all been surprised that we are still using this way of building plugins...
...does that imply that all the "current" (i.e.- v7) NativeScript Plugin documentation is no longer valid/applicable?
e.g. - Plugin Reference and tns plugin build
Or is there updated {N} documentation that I am missing regarding how to create/manage {N} plugin projects using the NX project build paradigm?
I am migrating a {N} v6 plugin to be compatible with {N} v7/8, which is how I found myself in {N} "legacy-land". I have completed the required modifications to the plugin's Typescript and native source code for both platforms such that it is now compatible with {N} v7/8. I am now simply attempting to use tns plugin build
to create the plugin archive. Creating the .tgz
archive is simple enough. What I am relying on the tns plugin build
command to do is generate the .aar
archive for the Android platform.
@grigala (or anyone else reading this) - do know if there is a version of {N} I could "fallback to" where the logic associated with the tns plugin build
build command has not yet been munged to work with the NX project build paradigm?
@grfalk
...does that imply that all the "current" (i.e.- v7) NativeScript Plugin documentation is no longer valid/applicable?
No, it's valid if you are building with an older CLI tools. They introduced this bug in v8.2 I think.
Documentation is a mess to be honest, they didn't migrate from v7 to v8 properly, and I often find myself in the situation when the documentation is available for v7 but nowhere to be found for current
. 🤷♂️
So, after my last discussion with the core members, they all admitted that it's clearly a bug they've introduced, but they've all been surprised that we are still using this way of building plugins, which apparently is considered kind of "legacy" way of doing it (broken legacy way), and they themselves haven't been doing it in this way for a long time. Instead, they are using NX workspace way, like packing the sources directly.
So... if I "read between the lines", this issue is low priority (an assumption on my part because it has been open since 2022-03) because it does not negatively affecting the (newer) NX-based build approach for plugins (or possibly supports it?), yet broke the (now legacy?) tns plugin build
functionality that has been a part of the {N} architecture for years? And at the same time, the move to the NX build approach for plugins has not been documented, nor have details been provided for migrating "legacy" plugin projects to the NX build paradigm?
I am aware that with the release of {N} v7, the {N} team updated all the {N} team-managed plugins to be compatible and consolidated them into a single repo project managed by NX. Using NX to manage a repo that is composed of 34 (formerly standalone) plugin subprojects makes sense to do. But expecting all organizations/individuals in the {N} community that use custom (or extended {N}-managed) plugins to spontaneously do the same without any official notification or documentation is questionable (at best). Organizations that utilize plugins in their {N} app(s) must be given notice, and need to be allotted time, to make such a migration for {N}-based products that are used in production scenarios. Moreover, use of the tns plugin build
command, coupled with a few shell scripts, is all that I currently need to manage my one custom {N} plugin project.
OK - I am done venting. Back to this issue.
@grigala I tried falling back to {N} v8.1.x, but ran into issues apparently related to #1706 and #9814 (and both have been closed with "fixed in v8.2.x" as the solution). I also briefly tried falling back to {N} v7.x.y and ran into different issues when attempting to build my plugin using the tns plugin build
command. Were you successful in any attempt to build your plugins with any {N} v7.0.0 or greater?
The big problem that I was finding very annoying up until now was the fact that the temp directory from where the error is thrown was being deleted immediately. Fortunately, I've managed to by watching the directory and copying everything recursively obtain a copy of the project that is generated.
@grigala Because I need to update my custom plugin in short order, I used your approach (quoted above) to "capture" the gradle project created by the execution of the tns plugin build
command (using {N} v6.x.y). I am going to apply various "tooling version" updates to this project's references, then incorporate it into my custom plugin's build process in order build the version of my custom plugin that is compatible with {N} v7/8.
In the meantime, I will wait to see what the {N} team decides to do about the functionality tns plugin build
command (if anything).
@grigala Thank you again for you replies 🙏. They have proven to be quite helpful.
Hi, I also digged into this ....and also found some PR that are open regarding the android build process, namely https://github.com/NativeScript/nativescript-cli/pull/5671 and https://github.com/NativeScript/nativescript-cli/pull/5578 maaybe those could help to fix this problem as in "simplify the current situation and then buld a clean solution on top of it? WDYT @farfromrefug ?
@madmas it could fix it. You can all easily test this by pulling my main branch, build and test with it
For everyone following, I can confirm that you can do the following to fix it:
.aar
file from your platforms/android
folder.npmignore
file:
tns plugin build
part and scripts from your build process See this commit for an example in my project.
This way it will ship the sources in platforms/android
in your npm package and {N} will build it when people run an application that uses your plugin.
@grfalk Try with this version (https://www.npmjs.com/package/nativescript/v/8.1.5-next-02-20-2022-1872272336). As I tested with this version, gradle issue is fixed while dependencies.json issue is not yet introduced.
Issue Description
When running ns plugin build using NS CLI 8.2.x, the following error raises:
Rolling back to CLI 8.1.5 temporally fixes the problem (defaults to targetSdk 31 and buildTools 30.0.3).
Reproduction
https://github.com/GeoTecINIT/nativescript-context-apis
Relevant log output (if applicable)
Dependencies
Please accept these terms