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.
Related
how do I solve this
The output directory is under your source tree
warning:the output directory is under your source tree
your generated files may get interpreted as source code
consider building into a different directory instead meteor build ../output
I apologize for my ignorance on this matter, I am new in the world of programming and meteor. about my case. 1. I have a folder on Desk called “Findme” where I have the structure of my project (the code and everything which forms the application which works) 2. Then through the console I access that directory findme and then run the command meteor build/Desktop/MyApp --server = https: //findme.com, and start downloading. 3. But inside the console I also get the message indicated before and when it is finished, and I check the folder MyApp, it is empty. 4. And when I check the Findme folder it has created a folder named ~ and inside displays a file called Desktop/MyApp but it also doesn’t have any useful files, only winrar and nothing useful. 5. I am trying to generate the apk, could you please let me know what I might be doing wrong? Is there another way to generate the apk? I would appreciate it if you could help me!
Your should specify a path for where to build your application that is outside of your project directory.
Otherwise this can lead to problems with Meteor's file watcher and as your error already pointed out:
your generated files may get interpreted as source code consider
building into a different directory instead
So if your command uses a relative path, as used in meteor build ../output then it is important to call this command at the most upper project folder.
Consider the following project structure:
/myapp
/client
/import
/server
If you call meteor build ../output from within /myapp it will generate the output folder as expected outside of the project:
/output
/myapp
/client
/import
/server
However if you call it from within a subfolder, say /myapp/imports it may generate the output within the project like so:
/myapp
/client
/import
/output
/server
So keep this in mind when building your app.
Further readings:
https://guide.meteor.com/deployment.html#custom-deployment
https://docs.meteor.com/commandline.html#meteorbuild
When i publish a dotnet core project, it generated a single folder with hundreds of framework and native runtime files in it.
I understand that these files are required to make everything work, but can i move them into a subfolder and still get my app to run?
For example
MYAppFolder\
MyApp.exe
MyApp.exe.config
native\
hostfxr.dll
netstandard.dll
...
Is there some sort of probing path configuration that can do this?
As far as I can see you have a Standalone (SCD) app.
For that type of deployment hostfxr.dll should always exist in the app directory by convention.
As to other deps, you are able to move them to any locations, however you'll need to edit [AppName].deps.json for every build and also specify Additional probing paths. Besides, you are free to remove all the redundant dependencies (from deps.json and the file itself) if you are sure that you don't use them.
Check this demo where I've put all the dependencies of a Standalone app that could be moved to other location to a lib subdirectory.
please, note the following:
Additional probing path is set in HelloWorld.runtimeconfig.json but you can also use --additionalprobingpath [path] argument or Environment varibable
I've removed relative paths in deps.json file because otherwise I would have put the files to those relative paths sub directories - Additional probing path is considered to be a NuGet package cache thus have a package layout inside.
Also, consider having a Portable (FDD) type. You'll have a much less footprint and more flexibility arranging the files.
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.
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
I have a simple sbt application that uses typesafe-config library and is build using sbt-native-packager.
I build it using following command:
sbt universal:packageBin
Within the src directory I have following hierarchy:
main/resources/application.conf
test/resources/application.conf
staging/resources/application.conf
And my archive always ends up containing only the main version of application.conf
I'm looking for a easy way to include specific application.conf file based on for example java property passed during project build, but I'm unable to find anything.
Have you taken a look at the mappings facility, which allows you to add/remove files from the base layout? See Change-Remove Top Level Directory In Output in the official docs.