I wanted to use this popup component from GitHub
I installed it using npm (I don't know how to do it otherwise).
I imported it to my App.js
import { Root, Popup } from 'popup-ui'
After importing it, I get this message:
Could not find a declaration file for module 'popup-ui'.
'c:/Repos/Budgeteer/node_modules/popup-ui/index.js' implicitly has an 'any' type.
Try npm install #types/popup-ui if it exists or add a new declaration (.d.ts) file containing `declare module'popup-ui';
`ts(7016)
#types/popup-ui does not exist. I got no idea what declaration means (total noob here). And I looked up ts(7016), and again I couldn't figure out what to do exactly, being a beginner.
When compiling, I get this issue:
C:/Repos/Budgeteer/node_modules/popup-ui/src/basic/Popup/index.js 10:1
Module parse failed: Unexpected token (10:1)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.
See https://webpack.js.org/concepts#loaders
the error comes with this piece of code:
| static popupInstance
|
> static show({ ...config }) {"
| this.popupInstance.start(config)
| }
I took a look at the link and read up on loaders, but I got no idea what type of loader I need to install, how to install it or how to edit that webpack file. I can't even seem to find it.
Any help would be deeply appreciated. But please try to make it as detailed as possible, because I'm new to all of this.
Also, I'm using React Native with Expo if that matters.
Cheers.
If webpack is running tsc (the Typescript compiler) and it's complaining about a .d.ts, that's weird. If Webpack is saying "I don't have a loader defined for .d.ts files", that means something is trying to require a .d.ts, which should never happen.
I've had this problem when people have a broad Context defined, either via require.context(/too-many-files.*\.ts/), or require("/some/path/" + fileName). Webpack will try to statically analyze the latter statement, and treat (more or less) as require.context(/\/some\/path\/.*/)
Either way you wind up with it grabbing .d.ts files when it shouldn't. If you can fix the require / require.context so it excludes the typings, do that. If you can't, add a rule like {test: /\.d\.ts$/, use: "null-loader"}
Related
I'm brand new to the front-end and I'm likely very dumb. However, in a nutshell, if I do this
yarn add #mapbox/polyline
I suddenly get all kinds of helpful errors like this when I yarn start:
undefined
TypeScript error in undefined(undefined,undefined):
Cannot find type definition file for 'bin'. TS2688
undefined
TypeScript error in undefined(undefined,undefined):
Cannot find type definition file for 'src'. TS2688
index.js:1 undefined
TypeScript error in undefined(undefined,undefined):
Cannot find type definition file for 'test'. TS2688
Ok cool. So I've royally broken this (git) branch (been there!), so let's just switch back to the working master branch... but yarn start yields the same errors on master now! It's as if the mere act of typing yarn add #mapbox/polyline corrupts something locally so badly that it's unrecoverable. I end up having to clone my repo again and start fresh.
(Since I'm using Typescript, I also tried adding types yarn add #types/mapbox__polyline... this does nothing to alleviate my pain.)
Any idea how to fix this?
Just in case it helps anyone else, adding "types": [] to compilerOptions in tsconfig.json fixed it.
I have no clear idea why this works. I just decided to try the suggestion found in this bug report, which I'm not sure is related.
This error happens because you have "garbage" inside node_modules/#types and/or your tsconfig.json is not configured properly. In order to understand exactly what's going on you need to know the following about TypeScript:
There are two fields in tsconfig.json related to this issue: "typeRoots" and "types"
{
"compilerOptions": {
"typeRoots": [],
"types": []
}
}
"typeRoots" specifies where TypeScript will be looking for "types" (I'll talk about what a type is shortly). If there is no "typeRoots" in tsconfig.json then TypeScript looks for types in node_modules/#types/.
So, what is considered a "type"? A type is a folder with index.d.ts file inside of it (or a folder with package.json inside of it specifying a different path/name to the type file).
"types" limits "typeRoots" by allowing TypeScript to look for types only into the folders which names are specified in "typeRoots". E.g. if your tsconfig.json contains:
{
"compilerOptions": {
...
"typeRoots": ['./node_modules/#types'],
"types": ['aaaaaa'],
...
},
...
}
then only ./node_modules/#types/aaaaaa will be used for types, and ./node_modules/#types/bbbbbb will be ignored (actually, it will be only partly ignored, only globals inside of it will be ignored, the other information about types inside of it will be used as usual).
So, in your case (assuming you don't have "typeRoots" in your tsconfig.json) it's very likely you get "Cannot find type definition file for" error because you have garbage (i.e. subdirectories that do not contain index.d.ts files) inside your node_modules/#types after running yarn add #mapbox/polyline. This would also explain why this error is not fixed when you switch git branches (because git doesn't track node_modules).
Typically you would add the #types\mapbox\polyline package.
However the typings may not exist
If you want to suppress these (if the types don't exist) you can add a file to your project
mapbox-polyline.d.ts (or whichever name you choose as long as it ends with .d.ts)
with the current contents
declare module '#mapbox/polyline'
Update: I've tested adding this package and
yarn add mapbox/polyline appears to import it.
However the git repo says that polyline has been deprecated in favour of #mapbox/polyline so it's possible the typings authors havent caught up.
Update: I'd suggest to uninstall the packages you have right now, then reinstall with the latest version of #mapbox/polyline with yarn add #mapbox/polyline, then supress the typescrpt warnings by adding the ambient declaration above for now.
I am trying to build echidna using stack install.
https://github.com/crytic/echidna
I am continuously getting the missing library error while installing at a progress state of 171/178.
I believe it to be more of stack error than library error. Error shown is as follows
I have tried installing the library but not getting any C library of such sort.ye
SO, i've installed every library using
sudo apt-get install lib*ff*-dev
isn't working yet.
-- While building package hevm-0.31 using:
/home/aman/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.3 --builddir=.stack-work/dist/x86_64-linux/Cabal-2.2.0.1 configure --with-ghc=/home/aman/.stack/programs/x86_64-linux/ghc-8.4.3/bin/ghc --with-ghc-pkg=/home/aman/.stack/programs/x86_64-linux/ghc-8.4.3/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/aman/.stack/snapshots/x86_64-linux/lts-12.10/8.4.3/pkgdb --package-db=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/pkgdb --libdir=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/lib --bindir=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/bin --datadir=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/share --libexecdir=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/libexec --sysconfdir=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/etc --docdir=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/doc/hevm-0.31 --htmldir=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/doc/hevm-0.31 --haddockdir=/home/aman/Desktop/new/echidna2/echidna/.stack-work/install/x86_64-linux/lts-12.10/8.4.3/doc/hevm-0.31 --dependency=QuickCheck=QuickCheck-2.11.3-3XHQpBYb83U2mMvNz2AjQX --dependency=abstract-par=abstract-par-0.3.3-Ie3MD7O3orK6ZR8i7FuBEv --dependency=aeson=aeson-1.3.1.1-7JlrwYHW7OR9ca4RRZ9oOf --dependency=ansi-wl-pprint=ansi-wl-pprint-0.6.8.2-9fh9v74MJQDJeSHE7X3Co6 --dependency=async=async-2.2.1-7DQr5PBcpiwJNOuf7ZiSPa --dependency=base=base-4.11.1.0 --dependency=base16-bytestring=base16-bytestring-0.1.1.6-I0igvRcEwRNBMqqPC2yQBh --dependency=base64-bytestring=base64-bytestring-1.0.0.1-4OCIe2BZn8jKI191JIXI37 --dependency=binary=binary-0.8.5.1 --dependency=brick=brick-0.37.2-HmDqAExuwtV4o98FRmS9eK --dependency=bytestring=bytestring-0.10.8.2 --dependency=cereal=cereal-0.5.7.0-ILaYAmVTyR1IcEsGXXUCfI --dependency=containers=containers-0.5.11.0 --dependency=cryptonite=cryptonite-0.25-GgyZs9E1viv2owjaLxA3vq --dependency=data-dword=data-dword-0.3.1.2-CMzWV6RCGtK8L6wsVSErKS --dependency=deepseq=deepseq-1.4.3.0 --dependency=directory=directory-1.3.1.5 --dependency=fgl=fgl-5.6.0.0-E3fRSNebqkULRqplV3ljSc --dependency=filepath=filepath-1.4.2 --dependency=ghci-pretty=ghci-pretty-0.0.2-I5PJbL8ge6MChp3KxZbHqH --dependency=haskeline=haskeline-0.7.4.3-5EI2v7Zmtnz57a7mmnEGOS --dependency=lens=lens-4.16.1-B0f4CyKKTUGAKBzzY965AX --dependency=lens-aeson=lens-aeson-1.0.2-Jly9eqrxMbj6GutGwOKn69 --dependency=megaparsec=megaparsec-6.5.0-G48ltiRFbVUHATB1lTnNRx --dependency=memory=memory-0.14.16-GTCi0eCrvrnI3inLDBWVMK --dependency=monad-par=monad-par-0.3.4.8-Jjk0JT5qYVK4xEO13GFUu8 --dependency=mtl=mtl-2.2.2 --dependency=multiset=multiset-0.3.4.1-DOPR5uXspss8vZY4jdOdOo --dependency=operational=operational-0.2.3.5-4jEcCWo4nKu1T4LZlKqe58 --dependency=optparse-generic=optparse-generic-1.3.0-1jcIewFKPXBLcRetZisV2l --dependency=process=process-1.6.3.0 --dependency=quickcheck-text=quickcheck-text-0.1.2.1-2lR7Kay7WBV5AMKAdKDpZZ --dependency=regex-tdfa=regex-tdfa-1.2.3.1-9PkkapJrmiKFVG38JA02jN --dependency=restless-git=restless-git-0.7-83nBoDMPYLtJIx01bvXzKs --dependency=rosezipper=rosezipper-0.2-GAlMD5j8Qb83GzjCYQknnx --dependency=s-cargot=s-cargot-0.1.4.0-J9AhWfrUxDQ6YMTyzXkHth --dependency=scientific=scientific-0.3.6.2-5di0UflhS5I1xpiiCPzjKz --dependency=semver-range=semver-range-0.2.7-dBvW3ofcsgDQf0zazTsJd --dependency=temporary=temporary-1.3-5Z6bOFbSCb7VhnH5UnI2r --dependency=text=text-1.2.3.0 --dependency=text-format=text-format-0.3.2-Fd261TSu6ptAAzilVN6BFx --dependency=time=time-1.8.0.2 --dependency=transformers=transformers-0.5.5.0 --dependency=tree-view=tree-view-0.5-Kkrk0dCM0oj2Q4xwPbd7Gg --dependency=unordered-containers=unordered-containers-0.2.9.0-IkfpzvG0LzrHAbTzfMidvY --dependency=vector=vector-0.12.0.1-4awQG9XUvVEBfJgKGHBhOb --dependency=vty=vty-5.21-A2OCwk39Wv3J3RjR3BvHey --dependency=witherable=witherable-0.2-2RYbFmOnVolGAqiDDS1CLe --dependency=wreq=wreq-0.5.2.1-IjuXB0jwsxA7O3uIVjcJXu --extra-include-dirs=/home/aman/Downloads/Compressed/ff13c/source/ --extra-include-dirs=/usr/local/opt/readline/include --extra-lib-dirs=/usr/local/opt/readline/lib
Process exited with code: ExitFailure 1
Logs have been written to: /home/aman/Desktop/new/echidna2/echidna/.stack-work/logs/hevm-0.31.log
Configuring hevm-0.31...
Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.3: Missing dependency on a foreign
library:
* Missing (or bad) C library: ff
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.If the
library file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
The stack install must find this library and end up successfully installing the library I'm using.
So, it is clear from the error provided above, that the installation was not able to find the libff file.
The best solution is to build the libff library manually and copy the required builds at the place it should be.
The best way to debug the problem is to look at the executed command closely and try to find the possible places where the libff should be...
Looking into the very 2nd error line, i.e. the complete command it was trying to execute
here, I sighted the following options being executed
--extra-include-dirs=/usr/local/opt/readline/include --extra-lib-dirs=/usr/local/opt/readline/lib
In order to solve this, I looked for the required libff library and cloned it from GitHub. I cloned the required dependencies and places them in the directory it should be.
https://github.com/scipr-lab/libff
I then followed the "Build guide" to build the required library.
Then with the superuser on, I created the directories, /usr/local/opt/readline/lib and /usr/local/opt/readline/include, and it was solved. And pasted the required builds in it.
Used stack install again, and it worked.
Note:
I thought many beginners may have similar problem while installing the required tools for their use. These small ideas may help them.
Migrating a react app built with ParcelJS to Typescript/React, I encounter some environment variables issues. Actually, the issue seems to only impact the error output since the environment variables (URL, used in a <a> tag) works properly on the webpage.
Here is the terminal output:
/Users/---/Projects/---/---/src/cart/index.tsx(xxx,xxx)
Cannot find name 'process'.
126 | method: "post",
127 | url: `${process.env.URL}/checkout`,
| ^^^^^^^
128 | data: cart,
I tried several approaches, as import * as process from "process" which didn't fix the issue:
Could not find a declaration file for module 'process'.
'./node_modules/process/index.js' implicitly has an 'any' type.
Try `npm install #types/process` if it exists or add a new
declaration (.d.ts) file containing `declare module 'process';`
> 6 | import * as process from "process";
| ^^^^^^^^^
Nevertheless if I try to output the variable that works :
const ENV = process.env.MIDDLEWARE_URL;
console.log('ENV', ENV);
Browser output:
ENV http://localhost:3000
Finally, I can't figure out if this is a Parcel issue or a TSConfig issue.
Any ideas?
In Node.js TypeScript development, #types/node package is supposed to be used for Node-specific declarations including process. It isn't suitable for browser because it likely has nothing in common with Node.js environment except process global.
process built-in module import is redundant in Node.js and certainly shouldn't be used in browser, because there's no such module (even though there is shim module, it isn't needed for process.env).
If process was defined by a bundler (ParcelJS) in client-side script, type declaration should be provided for it in custom type file (e.g. typings/custom.d.ts):
declare const process: {
env: {
ENV: string;
URL: string;
}
}
Custom typings path should be specified in TypeScript configuration as well:
"typeRoots": ["./node_modules/#types", "./typings"]
To add to a comment answer left by #Kleioz because I still had to google what was happening...
The solution was to add typeRoots to the TypeScript config. This essentially tells the compiler where the node_module declarations are. You can also pass through a folder for custom declarations if required.
{
"compilerOptions": {
...
"typeRoots": ["./node_modules/#types", "./typings"]
...
}
}
./typings is your folder for custom declarations.
Installing the correct type definitions as a dev dependency solves the problem: npm install #types/parcel-bundler --save-dev
Just starting with Ionic 2. My first app fails with error:
Error: Import directives may not be used within control directives or mixins.
on line 34 of node_modules/ionic-angular/components.core.scss
#import "fonts/ionicons";
Anyone encountered this problem and knows how to solve it? Would be very grateful for your help!
I found a solution for this:
One of the dependencies has updated (one that is related to sass). In order to fix this issue without changing the files under node-modules is to use specific versions for gulp-sass and node-sass. Use the following commands:
npm install gulp-sass#2.2.0
npm install node-sass#3.4.2
In the current beta (v2.0.0-beta.5) combined with Sass Sass 3.4.13 there seems to be a bug with an #import inside an #if. This is not allowed.
Comment out the #if structure in node_modules/iconic_angular/components.core.scss to look like this:
$ionicons: true !default;
// #if ($ionicons) {
#import "fonts/ionicons";
// }
On top of that there seems to be an issue with some declarations in the Sass file for windows. If you don't need Windows for now change the sass include defintion in node_modules/ionic-gulp-sass-build/index.js to read (so removing the include for windows).
...
src: 'app/theme/app.+(ios|md).scss',
...
This bug fixed in ionic "2.0.0-beta.6" version. You can update or check this commit fix saas errors
Go to node_modules/ionic-angular/components.core.scss and set the variable ($ionicons) to false.
I'm new to Arduino. When Arduino verifies this sketch https://github.com/MediaTek-Labs/Real-Time-Bicycle-Tracking-Map-using-PubNub throws the following:
Build options changed, rebuilding all
BikeTracker.ino: In function 'void setup()':
BikeTracker.ino:45:5: error: 'PubNub' was not declared in this scope
BikeTracker.ino: In function 'void loop()':
BikeTracker.ino:91:14: error: 'PubNub' was not declared in this scope
I've read most answers are pointing out to https://www.arduino.cc/en/Guide/Libraries some people say it's common Arduino linking issue (easy to fix) after tried out multiple approaches with no dice.
I've also followed PubNub customer support advice (with list of steps below) but no avail:
I got this from our hardware/IoT/embedded engineer:
You are probably not including all the libraries, or has the wrong
path for them.
When you download the source at
MediaTek-Labs/Real-Time-Bicycle-Tracking-Map-using-PubNub on GitHub:
Click .ino file and a pop up will ask if you need a new folder for the
sketch – click Yes.
Then copy the rest of the files from the source to
this new folder.
Compile it and see if you get any library path errors
that you need to provide. Let me know if you require further
assistance.
BTW this is my PubNub.h. Hope someone can shed some lights.
It turns out my Arduino IDE could not find PubNub.* files until I manually added them as Library.