I'm using the Immutable library (v4.0.0-rc2) and am trying to setup flow to use the typedefs included with the library. The typedefs are located at immutable/dist/immutable.js.flow, which I've duplicated under my project's ./flow-typed/npm directory.
The problem that I have is that flow works with every other module but Immutable and I keep getting an error whenever I attempt to include the module: required module not found.
Having inspected the contents of immutable.js.flow, there is no declare module block anywhere to be found, which I believe to be the cause of the error. There are a bunch of export statements at the end of the file though.
How can I include the typedefs so the thing just works? IOW, what can I do that doesn't involve providing the typedefs under a manually-created declare module block?
As you are using latest version of immutablejs library, all you need to do is install flow-typed library
Then just run
yarn flow-typed install
This should install all flow-typed dependencies based on your project's package.json and it will also create module declarations for any packages which don't have flow types yet.
And you don't need to copy any immutable flow definitions from node_modules to flow-typed/npm directory, because flow-typed will resolve automatically the flow types either from node_modules or from flow-typed/npm directory.
Related
We have a monorepo that uses Yarn’s ‘workspaces’ feature, meaning that whenever possible, Yarn will hoist dependencies to the monorepo's root node_modules directory rather than keep them in the individual package's node_modules dir. This relies on Node’s module resolving algorithm, which continues to search for modules in node_modules directories up the dir tree until it finds the required module.
When using Flow types in a file that imports another package (internal or external to the monorepo), running Flow inside the package that contains that file causes a Cannot resolve <package-name> error to be thrown. It seems like Flow uses a different module resolving algorithm, and fails since the installed modules are hoisted to the root dir and Flow does not continue to search up the dir tree.
Is there a way around this other than running Flow from the root? Running from the root is less than optimal because it does not allow different settings for different packages in the monorepo.
Node version: 10.8.0
flow-bin version: 0.78.0
I also ran into this problem
To fix it need update .flowconfig:
[include]
../../node_modules/
FS struct:
/project_root
--/node_modules
--/packages
----/module1
------.flowconfig
Pick the components to be hoisted by hand with a directive like:
"nohoist": ["**/npm-package", "**/npm-package/**"]
or select them with an exclude glob:
"nohoist": [
"**/!(my-site|my-cms|someones-components)"
]
See my answer to another question for more information.
Using jspm 0.16.13, I've noticed that in addition to mapping "a module alias to a location or package" config.js map also seems to be defining a module's dependencies. For example, see the snippet below. However, in this particular example, at least on my generated config.js, this module doesn't appear anywhere else in the map.
"github:aurelia/logging-console#0.7.1": {
"aurelia-logging": "github:aurelia/logging#0.7.0"
}
What I'm trying to do is create a "vendor" bundle using jspm... put all "third party" dependencies into it's own bundle. I need to manually list the modules because I'm using aurelia---including the "main aurelia module" won't automagically include it's dependencies. (That's probably true of other libraries as well.)
Can someone explain config.js map? Or provide a better way to list all of an app's dependencies?
You can use bundle arithmetic to bundle your app dependencies into a vendor.js:
jspm bundle app/**/* - [app/**/*] vendor.js
Explanation of the syntax by Guy Bedford: https://github.com/jspm/jspm-cli/issues/1109#issuecomment-141385673
An alternative solution is to bundle all modules listed in the package.json:
https://github.com/jspm/jspm-cli/issues/1109#issuecomment-139529178
As for the map, it defines aliases (or dependencies, does not really matter) so that import statements can refer to a module using a short name. In the future, it will be possible to import a module using an URL.
I'm currently trying to migrate an old ASP.NET WebSite project to Visual Studio 2015. I'd like to use NPM/Gulp to automatically compile LESS files to CSS (this task was done by WebEssentials in VS 2013).
I added a package.json file to the project to load the required components. This creates a node_modules folder in the root of the WebSite project, and this is where my problem starts:
Since WebSite projects don't have a project file, all files (and sub-directories) found in the project root folder, are automatically part of the project. Due to the deeply nested directory structure inside node_modules, this leads to errors because of too long path names.
An easy workaround is to set the hidden attribute on the node_modules folder (but this has to be done manually by each developer).
Is there a way to tell NPM to put the node modules into another directory e.g. one level above the project (..\node_modules) where the solution file is?
Or is it possible to set the hidden attribute on a folder from a gulp-task (which runs when the project is loaded)?
Based on #Rik's answer, I was able to solve the problem:
Instead of adding the package.json and gulpfile.js into the WebSite project, I added them at the solution level (as solution items). This means, that the node_modules folder is now in the solution directory at the same level as the WebSite project(s).
The only other change was to modify the paths in gulpfile.js accordingly.
You might want to check out npm 3.0+. It installs the modules in a maximally flat structure. It should reduce the paths lengths in the module directory.
From the release notes
Flat, flat, flat!
Your dependencies will now be installed maximally flat. Insofar as is
possible, all of your dependencies, and their dependencies, and THEIR
dependencies will be installed in your project's node_modules folder
with no nesting. You'll only see modules nested underneath one another
when two (or more) modules have conflicting dependencies.
#3697 This will hopefully eliminate most cases where windows users ended up with paths that were too long for Explorer and other
standard tools to deal with.
#6912 (#4761 #4037) This also means that your installs will be deduped from the start.
#5827 This deduping even extends to git deps.
#6936 (#5698) Various commands are dedupe aware now.
This has some implications for the behavior of other commands:
npm uninstall removes any dependencies of the module that you specified that aren't required by any other module. Previously, it
would only remove those that happened to be installed under it,
resulting in left over cruft if you'd ever deduped.
npm ls now shows you your dependency tree organized around what requires what, rather than where those modules are on disk.
#6937 npm dedupe now flattens the tree in addition to deduping.
https://github.com/npm/npm/releases/tag/v3.0.0
For upgrading the windows installation check out this package npm-windows-upgrade
There are two full build definition files in sbt project: Build.scala and Helpers.scala. They are located in project folder.
I'd like to put Helpers module into separate sub-folder project/utils. When I do import utils.Helpers in Build.scala it says:
not found: object utils
Is it possible to define directory structure that follows the packages in sbt full build definitions?
you should use project/src/main/scala/utils instead of project/utils
Sbt builds are recursive, which means that sbt build definition is built by sbt, applying the same rules as per normal project.
Unlike Java, Scala has no strict relation between the package and folder structure. Meaning you can place your sources wherever you like and it doesn't have to match package declaration. Scala will not complain.
Sbt knows where to search for folders by checking sourceDirectories setting key.
You can check it easily by executing show sourceDirectories. However this will show the sourceDirectories for your actual project. How you can check it for the build? Quite easily, execute reload plugins, this will take you to your build. Execute show sourceDirectories, and it should show you that it looks for sources in /project/src/main/scala, project/src/main/java and one more, which is managed sources (doesn't matter for our case). Now you can execute reload return to go back to your main project.
Given that you should be able to create an object let's say, named Helpers in project/src/main/scala/utils/Helpers.scala:
package utils
object Helpers {
def printFancy(name: String) = println(s">>$name<<")
}
And use it in your Build.scala:
import sbt._
import Keys._
import utils.Helpers._
object MyBuild extends Build {
val printProjectName = taskKey[Unit]("Prints fancy project name")
lazy val root = project.in(file(".")).settings(
printProjectName := printFancy(name.value)
)
}
You can test it by executing printProjectName.
> printProjectName
>>root<<
[success] Total time: 1 s, completed May 29, 2014 1:24:16 AM
I've stated earlier that sbt is recursive. This means, that if you want, you can use the same technique to configure the sbt build, as you use for configuring building of your own project.
If you don't want to keep your files under /project/src/main/scala, but just under /project/utils, you can do so by creating build.sbt in your project folder, with following content:
unmanagedSourceDirectories in Compile += baseDirectory.value / "utils"
Just as it is described in the documentation
Now even if you place your utils in project/utils sbt should be able to find it.
I have some compiled code inside my_project/java/classes. I also have all the libraries for that code in my_project/java/lib as jars.
For some reason I cannot get the jars inside that lib to be available so the java classes can access them.
Details: https://gist.github.com/anonymous/5219067
As you can see, I can interact with the library I'm trying to import. It definitely there, and it's on the classpath.
I've also tried without success several times now to try and build a 'fat' jar with all the dependencies bundled inside of it, using several ways, primarily Eclipse's Export with dependencies packaged inside the jar, and the jar index shows that it has all the dependencies as matlabcontrol/** included the InvokationException class just as the error shows.
When I imported the class it was giving me trouble with in the Program.java file, then upon calling that same Matlab.initialize() function, I got an error for a different class. So I'm wondering if I'm not building the classes correctly, so the "import 'matlabcontrol.*" aren't being resolved properly.