I added Flow to my React/Redux/Webpack project and initially, it was great, I loved the type annotations. Over time, I noticed that the start up time of the project became really slow - around 120s; it used to be around 20s. Upon investigation, I realized that it was because Flow was scanning through all the JS files in node_modules.
I attempted to ignore node_modules in .flowconfig by adding:
[ignore]
.*node_modules/.*
The start up became fast again but Flow would complain Required module not found in places where I import external libraries from my code.
A workaround suggested in this Github issue was to flowignore the node_modules and manually add interfaces for external libraries. This seems to work but is a hassle to maintain when new libraries are added into the project.
It's frustrating to have to wait almost 2 minutes each time I start the project, are there any better ideas?
One way to avoid the Required module not found errors would be to run flow-typed install which will fetch existing libdefs for popular libraries from the flow-typed repository. It also generates stubs for the libraries that cannot be found in it. This works great for many projects but in some rare cases, the stubs for certain libraries like Immutable.js were not generated.
I eventually came up with cli command flow-scripts to automatically generate the libdef stub interfaces such that I could flowignore node_modules but not get the Required module not found errors.
Simply run
$ flow-scripts stub
in the root of the repository and the libdef stubs will be automatically generated in flow-typed directory.
Related
I recently implemented serverside-rendering react app with code splitting using loadable-components
But it seems that loadable-components itself dependent on webpack, since loadable replaces jsonp_callback with its own reporter.
So what are the alternative options that we can use when using other bundlers like rollup, esbuild?
Do we have to manually walk through the react tree to pre configure which chunk is needed on which component unless there is no specific bundler targeted library like loadable-components when implementing code splitting on serverside rendering?
Is tsconfig typeRoots unnecessary?
First, let us consult the compiler options reference:
The documentation for typeRoots states (emphasis mine):
By default all visible #types packages are included in your compilation. Packages in node_modules/#types of any enclosing folder are considered visible. For example, that means packages within ./node_modules/#types/, ../node_modules/#types/, ../../node_modules/#types/, and so on.
If typeRoots is specified, only packages under typeRoots will be included.
That second line is important: if you don't set typeRoots then tsc defaults to looking for directories under node_modules containing #types in their directory names.
(The documentation doesn't say if it chooses node_modules because of the moduleResolution parameter though. (I suspect I'd need to dig-in tsc's source-code to find out for sure).)
If you do set a value for typeRoots than that overrides tsc's node_modules/**/#types* lookup logic and it will then only look in the specified directories.
As I know, I have to specify the path of the above file into typeRoots option of tsconfig file since typeRoots defaults to look into the node_modules/#types.
Not necessarily. You could also add your extra typings files' locations to the paths parameter and leave the typeRoots parameter blank/un-set, which means tsc will retain the "node_modules/#types-and-ancestor-walking behavior" but will see your .d.ts files just fine.
This scenario is mentioned in this TypeScript GitHub thread: https://github.com/microsoft/TypeScript/issues/13581
So if you're asking about your specific local environment on your machine: and assuming that you're sticking with the normative, typical (I dare say mainstream) TypeScript working idioms (such as using npm) then yes: you can remove the typeRoots parameter because tsc's (current) default behavior is to look for node_modules directories in the same location as your tsconfig.json.
(I understand that VS Code might also be pulling some strings behind-the-scenes to make tsc "aware" of your project files and dependencies and for its language-server process - but that shouldn't matter as you'll notice tsc should work identically from the command-line outside of VS Code).
If you're asking about the fundamental necessity of the typeRoots compiler option, and supposing that you're thinking "that because practically everyone is using npm and node_modules then why is the TypeScript team spending their time supporting unusual development configurations?"_ - well, for many very good reasons: tools shouldn't be dependent on other tools controlled by third-parties1: Consider the possibility that the npm ecosystem and/or NodeJS software could fall out of fashion overnight and then we'd be stuck with tsc's defaults still using node_modules when everyone is rockin' some new cool JS environment: there'd be headaches for many years to resolve the mess (not that the JS ecosystem isn't a mess as it is).
And there are many good reasons to not use npm and node_modules: people could be using TypeScript in an environment without internet access (think: secure software development, the defence industry, national secrets, etc) - those people in those situations might have a network share full of approved or known-trustworthy libraries that won't be using node_modules's naming convention - in which case if those people want to use d.ts files they'll need to manually configure the typeRoots parameter for themselves.
1 I'm aware that npm (which is legally separate from NodeJS, btw) is maintained by npm Inc, which is a subsidary of Microsoft (by way of being acquired by GitHub, also a Microsoft property), so having tsc depend on npm shouldn't be a problem - but that's a very recent thing: Microsoft only acquired npm 18 months ago in March 2020 - and Microsoft could very well spin-off npm Inc - or run it into the ground and everyone switches to yarn. So regardless of the end legal owners of whatever tooling is currently popular, you don't want unnecessary dependencies like that.
I try to find and also to delete all the unused libraries in a project. For example I have a folder lib/ with lot of other folder which are the famous libraries. I want to know how I can identify which libraries are not used.
I asked the same question here but the only response I received suggests to me to check each file one by one ...
Can you help me?
I don't think that is possible, as some libraries may be lazy loaded depending on some internal state of your application.
So even if you could somehow find all strong typed references inspecting the code, you have no way of finding out if a library is loaded via magic methods, custom class loaders, dynamically generated include or require statement, eval-ed code and so on.
Without having tests with 95%+ coverage for your non-library code, it is very risky to remove anything from your lib folder. You code may appear to run fine, but still fail in some edge cases.
There's an open source project that can help you to do that:
https://github.com/composer-unused/composer-unused
Installation
composer require composer-unused/composer-unused-plugin
Usage
composer unused
And if you want to use it inside phpstorm, you can look at their composer documentation: https://www.jetbrains.com/help/phpstorm/using-the-composer-dependency-manager.html#create-and-run-composer-scripts
I have a package which includes a file that gets frequently rebuilt. This causes meteor to restart each time that file is edited.
There are ways to get meteor to ignore files within the main app, eg putting inside a .directory but is there a way to do this within a package?
The catch is that I DO need the final file to be included for deployment, so it has to be named - as an asset - and included in the package addFiles.
The only solution I have so far is to host the asset external to the meteor app and load it in via http or something on each cold start, but that's a bit fragile.
As of Meteor v1.5.2.1, there is support for a .meteorignore file. It behaves the same as a .gitignore. Have you tried using it?
You can use them in any directory of your project and are fully integrated with the file watching system.
I'm using premake5 to build a complex application on multiple platforms. My application links against both static and shared/dynamic external libraries.
There seems to be significant build chain dependencies that break premake generated 'gmake' make files in this case.
Case in Point:
If you mix shared and static libraries in premake 'link' statements, GCC seems to get confused and expect your shared library references to actually be static libraries. When it can't find them the link stage fails. This is normally handled by prefixing your shared libs with '-Bdynamic'. Unfortunately there is no way to tell premake5 that an external link lib is static or dynamic, so you have to manually fixup the make files, which defeats the purpose of a build utility.
This is kind of a showstopper. I don't think you can just feed "-Bdynamic" into the linkoptions because it must be followed by the list of shared libraries.
Seems like a bug in gmake action (or at least a missing functionality)
For those, the best approach is to go to the Premake page on Github (https://github.com/premake/premake-core) and create a new issue.
And if you have the time to provide a small reproductible project (a static lib project, a dynamic one, and an application using both, each with only 1 cpp or some simple stuff + the premake script) and attach it to the issue, it would also be really appreciated (and much easier to treat this issue ^^)
I just started working with ant a few days ago. Right now I have a general buildall.xml which should call each project's build.xml. Because some projects depend on each other, I need to rebuild some other projects which depend on it. This isn't a problem--I'm just setting the depends property of the target. However, ant is always building the dependencies, even when the files haven't changed.
Let's say project1 has no dependencies; project2 depends on project1; project3 depends on project1, 2; project4 depends on project1, 2, and 3; and so on.
I could hack a solution which looks at project K, and checks if project 1 .. project K have updated files using uptodate. If so, then run the target. This is messy and appears unnecessary.
What is the cleanest way to implement this?
EDIT: So I decided to just hack in a bunch of targets, "check_projectK" where it does the uptodate checks on all of its source files, its build file, and the build files of the 1 .. K-1 projects. Due to dependencies, this is always handled correctly. However, this is still a large amount of copy and paste for a large workspace. I will leave this open.
Short answer, ANT can't do it, not unless you have some kind of way to connect to your version control system and check if anything has changed (you are using source control right?). Ant doesn't know about when what the last time a file changed and then see if it matches with what was built; it doesn't have the concept of a dependency repository. The whole purpose of Ant is that it just builds.
The solution to your problem isn't Ant, it's Maven. Maven HAS a dependency repository. There's also a very nifty plugin for Maven used specifically with Flex appropriately called FlexMojos. By using this, Maven can know when something was last built because it's uploaded to the repository. Then your other projects can add it's dependencies and download the SWC needed.
On top of that, it mixes great with a continuous integration engine like Hudson, Bamboo and Teamcity, which builds a project every time a file has been committed to your source control system, and then updates all dependent projects automatically!