The error occurs when I use the library in another library.
Library import is working fine in the app but not working within libraries.
And not able to generate the build of a library.
All libraries are publishable.
Error:
Nrwl.v13 Files Structure within lib folder:
Very difficult to debug. It can be related to circular dependency issue. Are you sure you don't import code from library which import code from the same library ?
A import B
B import A
If this is the case, you should handle this by creating a C library which will be imported by A and B or find a solution for the A or B which will not depend on each other.
Code example will be helpful for help you.
From https://github.com/nrwl/nx/issues/10785#issuecomment-1158916416:
There seems to have been an issue with a migration that was scheduled
for a version but the migration itself was released in another
version, so that might have caused the migration to not run in some
scenarios. That migration should have added the following in nx.json
for anyone having their nx.json extending from
nx/presets/core.json or nx/presets/npm.json:
{
...
"pluginsConfig": {
"#nrwl/js": {
"analyzeSourceFiles": true
}
}
}
Could you please add the above snippet to your nx.json and try again? If after applying the change it doesn't pick
it up immediately, run nx reset and then try again.
This didn't work for me though, so I opened nx issue #11583: library importing other library using wildcard path mapping fails with "is not under 'rootDir'"
I had this issue in one of our monorepo and it was caused by the fact that one of our library's name wasn't valid. We had something like #organisation/test-utils/e2e which we ended up renaming to #organisation/test-utils-e2e (take note of the / usage).
Related
I just put some of my code from a/b.dart to a/b1.dart file and now I started getting lot of errors on importing.
Is there any command or any other fix to import all a/b1.dart file in these files instead of manually opening each file and importing one by one.
I understand that a function or a property can be defined in more than two files and Dart can't make the right choice but if a function or property is defined in just one place, I think there must be some way to import it except searching for a/b.dart and replacing it with a/b.dart + a/b1.dart and then optimizing all imports.
As much as I am aware, Plugins/Extensions for your specific IDE (for dart) can be found that will help you with this problem.
I would recommend using dartdev tools - dartfix
I am trying to create a documentation for a Julia module using Documenter.jl. Now I imported a module which documenter cannot find for some reason. More explicitly: I imported SparseArrays.jl via import SparseArrays and am referencing SparseArrays.AbstractSparseArray in a docstring. (I also have SparseArrays.jl installed.) Yet I get ERROR: LoadError: UndefVarError: SparseArrays not defined. What's the reason and how can I fix this?
EDIT: This is what the relevant parts of the code look like:
module ExampleModule
import SparseArrays
include("example.jl")
end
example.jl:
"""
f
does stuff.
"""
function f(x::SparseArrays.AbstractSparseArray)
return
end
index.md:
```#docs
f(x::SparseArrays.AbstractSparseArray)
```
Most likely you have imported it in a separate code block. See here for an explanation of the issue.
Also you might need to add import SparseArrays in setup code as explained here. This is needed if e.g. you have doctests inside docstrings.
Here is an example how it is done in DataFrames.jl (in general DataFrames.jl has doctests enabled both in docstrings and in documentation code so you can have a look at the whole setup we have there).
If this is not the reason then could you please share your code in the question so that it can be inspected?
I'm having trouble using the Backendless plugin for Flutter.
I include
import 'package:backendless_sdk/backendless_sdk.dart';
(as per the instructions) and can then use e.g. Backendless.UserService. But if I try to generate a user to register, e.g.:
var user = new BackendlessUser();
user.setEmail("info#example.org");
user.setPassword("password");
Backendless.UserService.register(user);
I get an error Undefined class 'BackendlessUser' on the first line. This class is defined in src/modules/user_service.dat, which is exported by src/modules/modules.dartlike this:
library modules;
export 'cache.dart';
...
export 'user_service.dart';
which in turn is imported by backendless_sdk.dart like this:
import 'package:backendless_sdk/src/modules/modules.dart';
I would have thought that it would get imported indirectly by the import of backendless_sdk.dart, but apparently not. When I import it explicitly (with the same import statement, but now in my own code and not just indirectly in backendless_sdk.dart), I get a warning Don't import implementation files from another package. But it's not an implementation file; it's exported as part of the public API (at least that's what I understand the export statement to mean).
The Dart tutorial for creating packages suggests to place the export statements directly under lib, not in lib/src, so I'm wondering whether this is an error in the structure of the plugin, or whether I'm doing something wrong.
I'd be grateful both for a solution to this particular problem and also for pointers to how I can better understand packages, libraries, imports and exports in dart; unfortunately I don't find the language specification particularly helpful in this regard.
(The error and the warning are the same whether I use flutter analyze or IntelliJ IDEA.)
The problem has been fixed in the 0.0.3 version of the plugin. Please update the backendless_sdk version in your pubspec.yaml.
You can include the only one import now:
import 'package:backendless_sdk/backendless_sdk.dart';
Please also note, that there are some changes in the syntax. So for your example you should use:
var user = new BackendlessUser()
..email = "info#example.org"
..password = "password";
Backendless.userService.register(user);
Thanks for using Flutter SDK and pointing out this issue.
It's indeed the problem in the structure of the plugin. The Backendless team is aware of it and this problem will be fixed in the next release of the plugin.
For now you can import explicitly and suppress the warning.
I have one Fay file which is the heart of my program, however I need some helpers for my logic, for instance a method to replace substrings. From what I understand, if I need such methods which are offered by many Haskell libraries from Hackage directly, I can't use those Haskell libraries, but I must copy-paste the code in my project. So it's what I did, I copy-pasted a "replace" function together with other helpers from the MissingH library in a new file in my project: Utils.hs.
That Utils.hs compiles without problems with Fay. Also I import it in my main Fay file and I get a JS file for the main project file without problems. However at runtime I get the following error:
ReferenceError: Utils$$36$ is not defined
I don't think that Fay will include the code from the helper file in my main JS file, so I'm including both JS files in the loading HTML. And to make even more sure that when I load the main file, that the utils file is loaded, I load it like that:
$.getScript("Utils.js", function(){
$.getScript("FayConfig.js");
});
But despite this I still get the error. I tried compiling the Utils.hs with "--library" but it didn't help.
So my question is, which setup do I need to achieve that the generated JS will find the helper functions that I put in another HS file, knowing that at compile-time, Fay (apparently) finds them without problems? Is there an example of such a setup online? Most of the Fay uses that I found have all the code in a single HS file, though they often use external Fay code from cabal, as with fay-jquery. In my case, setting up a cabal project just for these simple helpers would be overkill.
Which version of Fay are you using (fay --version)? It seems like you are using a version older than
0.16 where forgetting import Prelude wouldn't give any warnings, see this closed ticket. So upgrade fay and/or add import Prelude.
We're also considering renaming operators in the produced output to make error messages like these easier to understand.
You do not need to invoke fay several times, fay outputs all dependencies into the same js file. So there's no difference from using a cabal package in that regard.
Hope this helps, otherwise please give me a way to reproduce this.
Today I cleared my .ivy cache and cleaned my project output targets. Since then I have been getting really strange behaviour when running tests with SBT or editing in the Scala IDE.
Given the following:
package com.abc.rest
import com.abc.utility.IdTLabel
I will get the following error:
object utility is not a member of package com.abc.rest.com.abc
Notice that com.abc is repeated twice, so it appears that the compiler uses the context of the current package when doing the import (maybe it's supposed to do this, but I never noticed it before).
Also, if I try to access classes in package com.abc from anywhere inside com.abc.rest (even using the full path) the compiler will complain that the type can not be found.
It appears that the errors only occur when I try to include files from parent packages. What I do find strange is that my code used to work. It only started happening after I cleaned up my project and my ivy cache, so maybe a later version of the compiler is more strict than the previous one.
I would love some ideas on what I can be doing wrong, or how I can go about troubleshooting this.
Update:
By first importing the parent classes and then defining the current package, the problem goes away:
import com.abc.utility.IdTLabel
import com.abs._
package com.abc.rest {
// Define classes belonging to com.abc.rest here
}
So this works, but I would still love to know why on earth the other way around worked, and then stopped working, and how on earth I can fix it. I had a good look, and could find no packages, objects or traits by the name of com anywhere inside the parent package.
Update relating to Worksheets:
Scala worksheets belonging to the same package share the same scope, which sounds obvious, but wasn't. Worksheets are not sand-boxed - they can see the project, and the project can see them. So all the 'test' object, traits, and classes you create inside the worksheet files, also becomes visible in the rest of the project.
I have so many worksheets that I did not even try to see where the problem came in. I simply moved them all to their own package, and like magic, the problem went away.
So, lesson learned for the day: If you create stuff inside worksheets, it's visible from outside the worksheet.
Anyway, this new found knowledge will come in handy, meaning anything 'interesting' can be build, monitored and tweaked inside the worksheet, while the rest of the project can actually use it. Quite cool actually.
It's still interesting to think how a sbt clean and cleaned up ivy cache managed to highlight the problem that was hidden before, but hey, that's another story....
(At the request of JacobusR, I'm making a proper answer out of my earlier comments).
This can happen if you have defined some class/trait/object inside package com.abc.rest.com. As soon as package com.abc.rest.com exists, and given that you are in package com.abc.rest, com would designate com.abc.rest.com as opposed to _root_.com. Fastest (but non-conclusive) way to check, without even scanning the source files, is to look for any .class files in the "com/abc/rest/com" sub-folder.
In particular you would get this behaviour if any of your files has duplicate package definitions (as in package com.abc.rest; package com.abc.rest; ...). If you have this duplicate package clause somewhere in the same file where you get the error, you wouldn't even see anything fishy with the .class files, as the failure at compiling the file would prevent the generation of .class files for any class definition inside the file.
The final bit of useful information is that as you found out the scala Worksheets are not sandboxed, and what you define in the worksheets affects your project's code (rather than only having the project's code affecting the worksheet). So a duplicate package clause in a worksheet could very well cause the error you got.
If package names conflict, there might be a custom error message for that. See if specifying the full path resolves the issue by starting from __root__. Ex. import __root__.com.foo.bar._