So I have been trying to learn ELM recently and I love it but I get stuck quite often. What I did in the code below is created a module and called it "Operation" then imported another module with a function I wanted to use. This is the task I was given by colleague as practice: "Create an Elm module called Operation. Import module StatusCalc and expose everything from it. Inside it create function “work” which receives an Int (called “exec”) as an argument, and returns Status. Its task is to call the function “checker” from module StatusCalc by giving it “exec” as an argument. I did the majority of it but the last part "Its task is to call the function “checker” from module StatusCalc by giving it “exec” as an argument".
Module: StatusCalc code:
module StatusCalc exposing (..)
type Status
= Started
| PartiallyDone
| Done
checker: Int -> Status
checker nameless =
if nameless <= 0 then Started
else if nameless < 10 then PartiallyDone
else Done
Module: Operation
module Operation exposing (..)
import StatusCalc exposing (..)
work: Int -> Status
I'm creating a module A that can extend functions defined in module B (which means module A may have using B or import B). However I don't want to load module B unless the user already has add B to their system. An example code would be like so:
module A
struct MyStruct{T}; end
if(#= module B exists =#)
import B: myFn
function myfn(x::MyStruct)
# ...
end
end
An analogy of this would be the use of #ifndef ... #define ... #endif in C++ header files. Is there a way for me to check that user has added B, and is this a good pattern to use when building modules?
In order to check if a package is installed on the user's system is to peek through the Base method Pkg.Installed (read more about it here):
"moduleB" ∈ keys(Pkg.installed())
returns True if the requested "moduleB" is installed.
If you need to find out that a package is loaded then use isdefined()
(Main, :moduleB)
Hope that helps!
I am receiving this warning message in my chrome console for my react-native project. Do you have any idea why I am getting this?
This is the complete message:
Require cycle: node_modules/react-native-radio-buttons/lib/index.js ->
node_modules/react-native-radio-buttons/lib/segmented-controls.js ->
node_modules/react-native-radio-buttons/lib/index.js
Require cycles are allowed, but can result in uninitialized values.
Consider refactoring to remove the need for a cycle.
I appreciate any suggestions.
Thanks
TL;DR: You import module A into module B and module B into module A resulting in a cycle A → B → A → B → A ..., which can result in errors. Resolve that by restructuring your modules, so that the cycle breaks.
Detailed Answer
In javascript if you import different modules into other modules all this importing generates a dependency tree:
root_module
┌───────────┴───────────┐
sub_module_A sub_module_B
┌────────┴────────┐
sub_module_C sub_module_D
When you run your code, all modules will be evaluated from bottom to top or from leaves to the trunk, so that for example if you import modules C and D into module B all exports of C and D are already evaluated and not undefined anymore. If module B would be evaluated before C and D, module B would be not working, because all exports from C and D would be undefined, since they have not been evaluated yet.
Still, it can be possible to form cycles in your dependency tree (this is what you got a warning for):
root_module
┌───────────┴───────────┐
sub_module_A sub_module_B
↑ ↓
sub_module_C
Problem: Let's say the evaluation starts now with module C. Since it imports something from module B and it has not been evaluated yet, module C is not working correctly. All imported stuff from B is undefined. This actually is not that bad, since in the end module C is evaluated once again when everything else has been evaluated, so that also C is working. The same goes if evaluation starts with module B.
BUT: If your code relies on a working module C from the very beginning, this will result in very hard to find errors. Therefore you get this error.
How to solve: In your case the warning also gives a detailed explanation, where the cycle emerges. You import native-radio-buttons/lib/segmented-controls.js in node_modules/react-native-radio-buttons/lib/index.js and node_modules/react-native-radio-buttons/lib/index.js in native-radio-buttons/lib/segmented-controls.js. It seems like the cycle is placed inside some of your node modules. In this case there is unfortunately no way you could solve that by yourself.
If the cycle is in your own code, you have to extract some exports into a third module / file, from which you import the code into both modules previously forming the cycle.
You are probably importing something from "file A" into "file B", then importing something again from "file B" into "file A" .
Examine all the imports from both the files and see if there's any such cycle.
To prevent from having to write multiple lines of
import SomeComponent from "../components"
import AnotherComponent from "../components"
import AndAnotherComponent from "../components"
import AndOneMoreComponent from "../components"
I created a comp.js file where I could import the components as they are created and export them as modules.
All components are then able to be reached from one place.
So you can then have something like this in some place...
import { SomeComponent, AnotherComponent, AndAnotherComponent, AndOneMoreComponent} from './comp'
Now what happens in the renderer for example when SomeComponent is rendered....
import * as React from "react";
import { AnotherComponent} from '../comps';
import { View, Text } from "react-native";
function SomeComponent() {
return (
<>
<AnotherComponent />
<View><Text>EXAMPLE OF SOMECOMPONENT</Text></View>
</>
)
}
export default SomeComponent;
In the example, SomeComponent could be called in the main App, and when it renders it also asks for a component from the comp.js
This is what triggers the Require cycle warning because a module that was imported from one place, is then rendering and asking to import another module from the same place it was rendered from.
What are your thoughts on this, should I revert back to using single import statements or do you think there is a danger in using the module export as it is currently setup?
I my case, I have sold the same problem in react-native navgiation.
What I did ?
Already I was using react-navigation like below
export const containerRef = createRef();
function App(){
return (
<NavigationContainer ref={containerRef}>
....
<NavigationContainer>
);
}
and then I was consuming it like:
import {containerRef} from 'filename';
onPress = ()=> containerRef.current.navigate('Chat');
But I updated like below and warning has gone.
function App(){
return (
<NavigationContainer> // removed ref
....
<NavigationContainer>
);
}
and then I was consuming it like:
import { useNavigation } from '#react-navigation/native';
onPress = ()=> useNavigation.navigate('Chat');
This occurs if your code contains cyclic dependencies. If these dependencies exist within your own libraries, you can easily fix them. But if this is happening in 3rd party libraries, you can't do much except waiting for the developers to fix these.
Another reason might be this: Some imports cause this warning if they're done through the require keyword. Replace these with import statements and you might be good to go. For example,
const abc = require("example"); // Don't use this syntax
import abc from "example" // Use this syntax instead
NOTE: This might vary from project to project. For a detailed understanding of require vs import, refer to this link.
In my case the warning was like this;
Require cycle: src\views\TeamVerification.js -> src\components\TeamVerificationListItem.js ->
src\views\TeamVerification.js Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
As it indicates, TeamVerification was importing TeamVerificationListItem and TeamVerificationListItem was also importing TeamVerification. It was an unused import but after I remove it the warning gone.
As others have already mentioned, for your own packages
Move things required within two modules by each other into a third module
Avoid imports from barrel-files (index.ts/js) or aliases (#mycompany/my-module) if you are within the same "my-module"
What others have not mentioned (and which seems to be the problem for OP), for packages not within your responsibility (eg node_modules from NPM), the only thing you can do is
Disable the warning. It will still show up in metro console, but no more yellow warning snackbar: import { LogBox } from 'react-native'; LogBox.ignoreLogs(['Require cycle: node_modules/']); You can place the code in App.tsx, for example.
Modify the package contents of the node_modules itself and patch the package contents after every npm install via patch-package => I think this is an overkill if the circular imports don't produce actual errors
You should use the Relation wrapper type in relation properties in ES Modules projects to avoid circular dependency issues, just click here: https://typeorm.io/#relations-in-esm-projects
In my case, i had the same warning after the installation of a 'package'
and in their documentation, it was import SomeFunc from 'package'
and instantly the warning showed up
Require cycles are allowed but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
but as soon as I destructure the SomeFunc there was no more warning
import {SomeFunc} from 'package'
please look at the destructuring
I used react-native-maps in my project and I got the same error.
Just upgraded from 0.27.1 -> 0.28.0.
I can confirm that this issue is fixed.
Thank you
if use NavigationContainer in #react-navigation/native
import {createRef} from 'react';
<NavigationContainer ref={createRef()}>
Please check whether you have imported same details within that file.
(i.e)
your file being as a actions/meals.js and you have added the line in the same file like
import { Something } from './actions/meals.js'
I've got a module m1 that needs to be initialized before I can import a module m2:
import * as m1 from 'm1';
m1.init(...)
import * as m2 from 'm2';
I updated browserify and switched from 6to5ify to babelify transformer. Afterwards, require calls in my bundle got moved to the top:
...
var _m1 = require('./m1');
var m1 = _interopRequireWildcard(_m1);
var _m2 = require('./m2');
var m2 = _interopRequireWildcard(_m2);
m1.init('init value');
...
Why are require calls moved to the top? Can I use ES6 module import syntax to import m2 after m1.init is called? I can use require directly
import * as m1 from 'm1';
m1.init(...)
const m2 = require('m2');
and I get
var _m1 = require('./m1');
var m1 = _interopRequireWildcard(_m1);
m1.init('init value');
var m2 = require('./m2');
but that seems like a hack to me.
Imports should be thought of as hoisted values in ES6. They are always at the top of the module. You are currently relying on an implicit dependency. If m2 relies on m1 not only being loaded, but also being initialized, then you should have a module that explicitly returns an initialized version of m1, then it should be depending on that explicitly or via import ordering if you can't directly modify m2, e.g.
init-m1.js
import * as m1 from 'm1';
m1.init(...)
export default m1;
init-m2.js
import m1 from './init-m1';
import * as m2 from 'm2';
Can I use ES6 module import syntax to import m2 after m1.init is called?
Irrespectively how Babel transpiles this code, the answer is: no. The spec dictates that all dependencies are evaluated before the module itself is evaluated (§15.2.1.16.5).
That means that import declarations are not evaluated when engine actually executes the code. They are statically analyzed and this information is somehow added to the module, so that the dependencies can be evaluated before the module itself is evaluated.
Even if you found a transpiler that would do what you want, it would not be spec compliant and your code could potentially break in the future.
I have modeled my project in alloy, and I want to separate the run part from the modeled part of my project.
In some fact and predicate I use the add function in cardinality comparison.
Here is an example :
#relation1 = add[ #(relation2), 1]
When the run part and the model part are in the same file all work successfully.
But when I separate them in 2 files, I have the following syntax error :
The name "add" cannot be found.
I thought it needed to open the integer module where there is an add function, so I have opened it it the header of the model part.
But then the runtime ask me to specify the scope of this/Univ.
You must specify a scope for sig "this/Univ"
Here is an example :
first the model in one module
module solo
open util/ordering [A] as chain
//open util/integer
sig A{ b : set B}
fact { all a : A - chain/last | #(a.next.b) = add[ #(a.b), 2]}
sig B{}
then the run part in another module :
module due
open solo
run {#(solo/chain/first.b) = 2 }for 10 B, 5 A
when I call it like this I have the "the name add cannot be found" error.
When I uncomment the integer module opening, I have the "You must specify a scope for sig "this/Univ"" error.
What should I do that to make it works?
If I'm not mistaken + is the union operator and thus can't be used to perform additions.
Which version of alloy are you using ?
I think the add[Int,Int] function was added recently, before it used to be plus[int,int].
You might want to try plus[Int,Int] and see if it solves your problem.
Else it would be nice to have access to your models. Maybe the error comes from elsewhere.