I have the following project structure:
root
src
scripts
main.js
foo.js
Inside of my main.js file, I'm importing foo.js like so:
import 'src/scripts/foo.js'
When I click on the import statement above and go to Navigate -> Declaration I get a super helpful message that says Cannot find declaration to go.
This makes it super frustrating to work with because the editor basically has no idea which files import other files. This means I can't use the helpful features of the IDE like search for references when moving a file, find usages, etc
If I change the import statement to be relative, it works altogether:
import './foo.js'
However, we are striving for absolute imports, a habit we picked up from writing python apps.
I came across Webstorm: "Cannot Resolve Directory" and that gave me the idea to mark my src directory as a Sources Root. After doing that, I could change my import statement in main.js to
import '/scripts/foo.js' //notice the leading forward slash
Well, that's a little better because now I can at least Navigate -> Declaration but it's not ideal because now I can't mark any of the directories underneath src as a test, resource, etc.
So why is IntelliJ/webstorm making this so difficult to do?
Because now I can't mark any of the directories underneath src as a test, resource, etc.
Yes, you can. It is not possible to mark subfolders of already marked folders in the Project View. But you can do this in Project Structure (Ctrl + Shift + Alt + S). Go to Modules, select your module and switch to the Sources tab. Now you can mark your src folder as Sources (which you already did) and mark src/test as Tests etc.
According to the Web Help, in WebStorm this setting is hidden in Settings > Directories instead of the Project Structure.
Here's another solution using only the Project View: unmark your source folder, mark your test/resource subfolders and then mark the (parent) source folder again. I'm not sure, why it doesn't work the other way around.
I would very much suggest against using this style of import in JavaScript code. While potentially workable, relative paths are the defacto standard in all NodeJS code, and that has spread to essentially all JS code that uses module systems.
In current systems, any path starting with . is relative, any path starting with / is absolute, and any other path is resolved to a module. By that logic, import 'src/scripts/foo.js' would be parsed as ./scripts/foo.js relative to a dependency module called src.
Note also that the file extension is optional and commonly left off.
If you want to use this style and your module loader supports it, you are of course free to do so, but I want to stress that you are likely bringing pain upon yourself by using a non-standard approach.
Related
The documentation I've read is rather hand-wavy about what exactly import does in Javascript, particularly in the Angular framework. I get that it imports modules from another file that has one or more exports. But there are many permutations of its syntax, and not all are discussed with much detail. I'm currently having a very hard time with the #asymmetik/ngx-leaflet-markercluster module. When I try to compile my Angular app, I get a message reading "Can't resolve 'leaflet.markercluster' in 'C:\sca_root\city8\node_modules#asymmetrik\ngx-leaflet-markercluster\dist\leaflet-markercluster" -- this is in reference to a line that reads simply
import 'leaflet.markercluster';
This seems to me (and I know, perhaps I am making too many assumptions here) that there should be a file in that same directory named leaflet.markercluster.js or perhaps leaflet.markercluster.ts (it's Javascript, not TypeScript, so it will be the former). But there is no file named leaflet.markercluster.js in that directory. These are the files in that directory:
leaflet-markercluster.directive.js.map
leaflet-markercluster.directive.metadata.json
leaflet-markercluster.module.d.ts
leaflet-markercluster.module.js
leaflet-markercluster.module.js.map
leaflet-markercluster.module.metadata.json
leaflet-markercluster.directive.d.ts
eaflet-markercluster.directive.js
Which one would that import statement import? If not any of them, where outside this directory would it import that file from? What other information (perhaps in tsconfig.json or angular.json) might affect where this import statement imports from?
the problem in this case was that leaflet.markercluster ALSO needs #types installed. i had to issue a
npm install #types/leaflet #types/leaflet.markercluster
i don't know why the error had nothing to do with #types, but this is in keeping with the soul-crushing nature of Angular development.
In a react application .i have the following file : (I am using VSCode)
#example .js
export default helloWorld =()=>{
return "Hello World" ;
Is there a way , i can look for all the .js files which imports this file ?.
I understand different files can have this function by the same name .
So is there a way we can look which files have used something like :
import helloWorld from "somevariablePath/example.js"
try show all references or find all ref
I had the same problem recently, and realized theres not a perfect solution for this. The CommonJS modules aren't well-suited for static analysis.
Anyway, I found useful following tools:
JetBrains Webstorm IDE (Premium)
The feature Find Usages from this IDE is the most accurate tool I found. But its a paid IDE. (You have a 30 days trial period)
VSCode
The feature Find all references is not as accurate as previous one, but still useful.
Well i figured out an easy way to do that in the VSCode.
If i just use the absolute path (the absolute path can of course be shortened by using NODE_PATH environment variable in the .env file) of the file which i want to track(see whereever it is imported) .
I can just copy the path , do a Ctrl+Shift+F ,paste the path in the search bar and press Enter(Pressing Enter is important).
This will give all the files where that particular line of code ,in this case , import helloWorld from "absolutePath/example.js,is used
checkout dynamic import feature of webpack if fits yours requirement .
Dynamic import
or iterate using the file system(fs module) and load the file based on your condition
I am using global variable __root with path of my root app directory then I am using require to load code from other files.
const Parser = require(__root + '/parsers/Parser')
The issue is that vscode does not understand what is happening:
Intellisense does not work
Object type is shown as any (if path is correct vscode grabs right type)
What are the options to solve this? Can you share your practices to resolve this issue?
VS Code's intellisense cannot understand dynamic import paths like root + '/path'. There are no workarounds for this, nor are the plans to address this in the immediate future.
However, with static require import paths, you can configure how VS Code resolves the imports by configuring a jsconfig.json. The two options you probably want are baseUrl and paths
Setting up a jsconfig.json will not change the runtime behavior of your code, only how VS Code IntelliSense handles your project. You can use a jsconfig.json along with webpack aliases
I have a library (ES6) which is composed on many sub-modules, say
- package.json
- lib
- my_package
- file1.js
- file2.js
- sub_module1
- file3.js
- file4.js
I currently do imports like this (all inside my package - using file resolution to find, not node_modules resolution):
import {func1} from 'lib/my_package/file1'
import {func3} 'lib/my_package/sub_module1/file3'
So, in practice I have many files across sub-directories.
I am now trying to package and publish my library, which will be installed under node_modules.
It seems to me that the node resolution algorithm (when behind node_modules) only allows for a single entry point (and there is nothing rollup can do about that)
I would like to be able to include many sub directories and files and for them to be resolved individually.
As far as I understand I have to include a single toplevel file that has all the export from machinery. I can only import that single top level file.
This means having to manually create that file. It also means losing the all the sub-module name structuring that comes from the directory structure.
I was wondering: is there any way one can import any other file from a node_module directly?
Node's resolution algorithm only resolves the first part of a module source, so if someone does this...
var foo = require('your-library/subdir/foo.js');
...then Node (or Browserify/Webpack/rollup-plugin-node-resolve) will correctly resolve that to
/path/to/project/node_modules/your-library/subdir/foo.js
The tricky part is that you want to author JavaScript modules, but if someone is using your library in Node then they need CommonJS modules. Rollup can't help you here — you would need to do a one-to-one ESM->CJS conversion for each module. So that means either using Babel, or authoring CommonJS modules in the first place.
In the context of a Node.js / Express / Angular2 / typescript (IDE=Visual Studio) app, I am trying to load a third party .js utility (packery) onto the client side (for use in a directive). Someone made typescript definitions for it. The d.ts file looks like:
declare module "packery" {
interface PackeryOptions { stuff... }
class Packery { stuff .... }
export = Packery;
}
I refer to this d.ts file, tell the browser where the .js packery script lives, and then import the module as such:
import Packery = require('packery');
This compiles without complaint. However, upon running, the browser attempts (and fails) to find "packery" at http://localhost/packery as opposed to knowing packery is an imported library. This is in contrast to the other import statements I have made on the client such as:
import {Http, HTTP_PROVIDERS} from 'angular2/http';
which work - as far as I can tell the only two pieces of information I gave it for those were also a d.ts file and the location of the .js file, just like packery. But, I must be missing something. Have tried many combinations of file locations and linking and can't get it to work. How can I get the proper linking to "packery"?
Thanks!
I found a workaround for this and thought I'd post in case it helps anyone, although I am still having difficulty with the setup posed in the original question, that is, getting statements of the type:
import foo = require('foo')
to run on the CLIENT side. These work for me in node.js on the server, but on the client, for third party libraries that have been loaded via a script tag, I cannot get it to work, even if I add mapping entries to the system.js config file, irrespective of if I point to a .js file or a d.ts file.
Anyway, what does work is if you load the library using the script tag, then in your IDE put a reference path as such at the top of the CLIENT side code
/// <reference path="foo.d.ts" />
and ensure that your d.ts file does not declare a module/namespace but rather exports methods etc. directly. This lets the IDE compile without complaint, and the client side code is able to access the third party library.
However, I'm not sure if it is preferable / best practices to do what I did or if one should be configuring System.js somehow.
Typings are empty definitions of js libraries that aren't written in a typed language. They are only useful in development for IDEs hints and stuff, in your app, you'll still use the library as you normally would, adding the js file in your index.html or w/e you load your js files from.