I am developing a React application whose environment is created using create-react-app and I added and I have the following folder structure:
src
|- components
|- styles
|- config.scss
|- reset.scss
|- common.scss
|- index.ts
in the middle of the common.scss file I use #use "src/styles/config.scss" and it works great, the preprocessor itself sees all the changes and functions from there, but not VSCode when I press Ctrl + Left Click, it throws me an alert with the inscription "Unable to open 'config'" and this complicates the development, since it does not see what functions are there and does not allow me to view them on my own when autocomplete is not working, I have to open folders and search for the file itself every time.
And here is the question, is it possible to somehow explain to VSCode that this #use "src/...." is the root of the src folder, since I checked the work in WebStorm, it works there itself, and it easily recognizes the paths and where they lead, I would like and here is such an opportunity (
You can try the below codes in jsconfig.json. These codes define absolutely path as src. But I am not sure the codes makes to click to link references.
{
"compilerOptions": {
"baseUrl": "src"
},
"exclude": ["node_modules", "build"],
"include": ["src"]
}
```
Related
I am wonder, if it is way how to enable autocompletion for WDIO global variables ( $, $$, browser ) in VSCode. I know, that wdio has support for Webstorm, but it doesn't work for VSCode.
Any idea, how to use autocompletion in VSCode? Without it is pretty hard to create some tests.
I struggled with this as well. Firstly, ensure you've followed the "Autocompletion" Setup described on the website; for example, they require something like the following exist in a file called jsconfig.json at the root of your project:
{
"include": [
"**/*.js",
"**/*.json",
"node_modules/#wdio/sync",
"node_modules/#wdio/mocha-framework"
]
}
You may already have a jsconfig.json; if so, ensure that the node_modules directories are not in a section called "exclude": { ... }. When setting up other things like Babel (for mocha) this may get installed as a default configuration entry. When node_modules is in both include and exclude, exclude takes precedence.
I had zero success importing npm #types pacakges, adding typeAcquisition: {} to jsconfig.json, or adding interface browser; into the file global.d.ts as other people have suggested in various forums.
Auto completion is pre-installed on vs code. If it is not working you might want to check through extension and install. And to use, once the open tag is created, it often auto suggest, just do appropriately then input your attribute.
Is there a way to automatically load libraries, change to a certain working directory, etc. when launching Dymola?
The question is slightly ambiguous - the other answer is quite good for one scenario. (The openModel call in Step 2 can be modified.)
However, if you always want to launch Dymola in a specific directory etc it is possible using the GUI. How depends on version.
Dymola 2020 x (and later)
Allows changing start-up directory through File>Working Directory
And has Tools>Library Management>Modelica Path where you can add the directory containing your external libraries.
To make libraries appear preloaded you have to add a libraryInfo.mos script in the corresponding library; you can look at Modelica Standard Library in the Dymola installation for inspiration.
The latter is described in more detail in the section "More about libraries and the building of menus of libraries and demo" (somewhere in the User Manual).
Dymola 2017 FD01 (and slightly differently from Dymola 2016 FD01):
Change Directory (File>Change Directory)
Add to Modelica Path (File>Modelica Path)
Save those settings (Edit>Options>Settings: Select Startup and Modelica Path)
If you want to "preload" libraries there are some options:
In a startup script you can use import MyPackage; or openModel("...\\MyPackage.mo"); alternatively if you are administrator you could modify Dymola/insert/dymodraw.ini and add a line: Dymola5LibraryMenu "MyPackage" (technically it doesn't "load" - it just shows the library in the package browser).
An important difference is that changing dymodraw.ini keeps the library "loaded" even after "Clear All".
In recent years there are two options that might help you.
File>Library Management>Install This dialog allows you to open a
zip-file or something similar of a distributed library, install it,
update MODELICAPATH to find it again, and even update the File>Libraries
menu to include it for future use. All in one operation.
Simulation>Edit startup.mos If you prefer to edit the startup
script, this is the convenient way to find it end open it for
editing.
Here is a procedure which allows to load a set of libraries with one click.
It makes use of the fact that the dymola.exe can be started with a .mos script as first argument.
It is designed for situations such as
You are using Windows
You are working on one or more projects
Where every project requires a set of libraries to be loaded
Every project uses it's own working directory
Other users might collaborate, so they need the very same setup
Requirements
The setup is a bit of work the first time, but very quickly done for further projects. You need:
a start.mos file in your library
the environment variables DYMOLA_WD and MODELICA_LIBS
(This is only required to allow other users to use different paths for their libraries and working directories)
a file short-cut to dymola.exe
This is how start.mos looks like for a specific project (usually you only change the first two lines):
// user setup
libs = {"Buildings 6.0.0", "PhotoVoltaics", "MyProject"}
wd = "myproject"
// open all libs
lib_dir = Modelica.Utilities.System.getEnvironmentVariable("MODELICA_LIBS");
lib_dir = Modelica.Utilities.Strings.replace(lib_dir, "\\", "/")
for l in libs loop
openModel(lib_dir + "/" + l + "/package.mo");
end for;
// change to wd
wd = Modelica.Utilities.System.getEnvironmentVariable("DYMOLA_WD") + "/" + wd;
wd = Modelica.Utilities.Strings.replace(wd, "\\", "/")
Modelica.Utilities.Files.createDirectory(wd)
cd(wd)
Now you create a shortcut to dymola.exe in the windows file explorer. In the field Target you set
"C:\Program Files\Dymola 2020\bin64\Dymola.exe" "%MODELICA_LIBS%\MyProject\Resources\scripts\start.mos"
Example
Assuming a user has set the environment variables
MODELICA_LIBS = E:\modelica
DYMOLA_WD = E:\dymola_wds
the folder structure on the users hard disk must look as follows for the script above to work:
E:\modelica
|- Buildings 6.0.0
|- package.mo
|- ...
|- PhotoVoltaics
|- package.mo
|- ...
|- MyProject
|- package.mo
|- ...
|- Resources
| |- scripts
| |- start.mos
|- ...
Now the dymola.exe-shortcut is used to start Dymola, which will automatically load the required libraries for the project and change the working directory.
For another project a new shortcut is required, along with a new start.mos script.
This method has been tested for Dymola 2017FD01. Prior versions used a different method via a setup.mos script that is no longer available. As of this posting, there is no option to perform this actions via the Dymola GUI.
It can be easily accomplished via a .mos file with the steps shown below:
Create a .mos file in a location that makes sense. For example, C:\Users\USERNAME\Documents\Dymola\startup.mos
Add the actions desired to .mos file. For example, to load a library add openModel("C:\\Users\\USERNAME\\Documents\\ModelicaLibrary\\package.mo");
Dymola always puts its auto-generated files in the current working directory. It's often a good idea to have that location be the same location so there is no need to hunt down the location of output files. Therefore, at the end of the .mos file change the current directory: cd("C:\\Users\\USERNAME\\Documents\\Dymola");
If no shortcut exists to the Dymola.exe file, then create one.
Right click the shortcut and go to Properties. Under Shortcut>Target append "C:\Users\USERNAME\Documents\Dymola\startup.mos"at the end. The contents of that cell should now look something like this: "C:\Program Files (x86)\Dymola 2017 FD01\bin64\Dymola.exe" "C:\Users\vmg\Documents\Dymola\startup.mos"
That's it. When Dymola is launched from that shortcut the actions specified in the .mos file should be carried out.
Another suggestion where you don't need to hardcode your package into an environment variable of your operating system (and maybe more safe for inexperienced programmers):
Go to the folder where Dymola is installed (e.g. C:\Program Files\Dymola 2020).
Search for the Dymola.mos file in the insert-folder. 'insert' folder
Open the script (e.g., in notepad++)
Add the link(s) to your Dymola-library-package.mo file(s) here with the openModel statement
e.g., openModel("C:/IDEAS/package.mo"); Dymola.mos script
Save the script. Now, every time you open Dymola, your libraries will be loaded automatically.
I have an Aurelia TypeScript project where my compiled JavaScript files go into the .../wwwroot subfolder and the original typescript files are located in .../src. I am trying to use the Chrome Debugger extension in VS code but breakpoints are not hit and when I turn on diagnosticLogging in launch.json the the mapped source is incorrect: It look in .../wwwroot/src/file.ts instead of .../src/file.ts.
I tried to solve this with sourceMapPathOverrides but with no success. It seems I cannot match my sourceRoot.
I tried this:
"webRoot": "${workspaceRoot}/wwwroot",
"sourceMapPathOverrides": {
"/src/*": "${workspaceRoot}/src/*"
},
This is the debug console output for finding the source to login.js:
›SourceMaps.loadSourceMapContents: Reading local sourcemap file from ...\wwwroot\dist\login.js.map
›SourceMap: creating for ...\wwwroot\dist\login.js
›SourceMap: sourceRoot: /src
›SourceMap: sources: ["login.ts"]
›SourceMap: webRoot: .../wwwroot
›SourceMap: resolved sourceRoot /src -> ...\wwwroot\src
›SourceMaps.scriptParsed: ...\wwwroot\dist\login.js was just loaded and has mapped sources: ["...\\wwwroot\\src\\login.ts"]
Note: The three dots ... stand for my removed path on disk to the project root.
How can I use sourceMapPathOverrides to have it lookup login.ts in .../src/?
Because of suggestion I tried to set webRoot to the workspaceRoot like this:
"webRoot": "${workspaceRoot}"
This way the mapped source file is correct and breakpoints work. But the log also says:
Paths.scriptParsed: could not resolve http://localhost:9000/dist/login.js to a file under webRoot: c:\Users\username\Source\Repos\myproject. It may be external or served directly from the server's memory (and that's OK).
The folder served by the webserver is the wwwroot subfolder in my project so from the description setting webRoot to workspaceRoot is wrong. What other problems might occur or is the suggestion of #Steffen valid?
To make sure, this is the folder structure
/ (project/source/git root)
/src (contains typescript, html files, is sourceRoot in source mapping)
/src/login.ts
/wwwroot (root folder served by dev web server, should be webRoot shouldn't it?)
/wwwroot/index.html (file opened by http://localhost:9000/ which starts Aurelia bootstrapper)
/wwwroot/config.js (SystemJS config, maps * to dist/* )
/wwwroot/dist (folder containing compiled application files)
/wwwroot/dist/login.js
It seems something is wrong with my installation (osx 10.11.3) but I can't determine why and i'm not sure how it worked prior to the February release of vs code.
For example:
var express = require('express'),
app = express();
app.post('/upload', function (req, res) {
//Some code
}
if I replace app.post with app.FOO it won't signal that there is an error and that foo is unknown. Also I don't get auto complete for 'post' after app.
Furthermore I don't get any light bulb that would allow to download the definitions from typescript to get auto complete.
What could cause this issue ?
(this is for Vs CODE, not standard vs)
Edit: also noticed this: when on a js file, when I change file type to let's say CSS, it will show all the errors of course because it's not a CSS file. When I revert back file type to js.... it will still show the errors of CSS ??!! I think this is a bug in the latest update. See attached image.
Edit: I manually added in project root a jsonfing.json file with:
{
"compilerOptions": {
"target": "ES6"
}
}
and I added a 'typings' folder in project root, with node, pg and express typings files.
I faced a similar issue it seems vscode team has removed the quick fix for type definitions in the release. We have to add the d.ts using below plugin
https://github.com/typings/typings
once you installed the typings for the library you wanted, you need to create a jsconfig.json file. Steps below
https://code.visualstudio.com/docs/languages/javascript#_javascript-projects-jsconfigjson
[note: i left this file empty]
Now the vs automatically loads the d.ts files if it is under typings directory
Below is the issue that I created in Github
https://github.com/Microsoft/vscode/issues/3867
Hope this helps
OK, I was able to reproduce this bug, seems like now you have to set up project with jsconfig.json and explicitly add excluded folders. Example jsconfig.json
{
"compilerOptions": {
"target": "ES5",
"module": "commonjs"
},
"exclude": [
"node_modules"
]
}
Also don't forget to "Reload Javascript Project".
More details https://github.com/Microsoft/vscode/issues/3901 and https://github.com/Microsoft/vscode/issues/3791
i'm setting up an environment to debug coffeescript file.
I'm using an IDE, webstorm, that genrates both .js file and .map from original .coffee file, from coffeescript default compiler.
So I endup with 4 files all in same folder:
main.html, aa.coffee, aa.js, aa.map.
in main.html I include the js file.
The JS files contains:
// Generated by CoffeeScript 1.6.3
var my;
my = 1;
alert(my);
/*
//# sourceMappingURL=aa.map
*/
Very simple. When loading main.html it correctly popup the alert.
Now when I open google dev tools / source, where I see the tree of my files, I see the html file and the js file. But it's IMPOSSIBLE to have the .coffee file appear, although correctly referenced as you can see above. Of course, I did enable sourcemap in dev tools settings. I wathed several video tutorial and I did all step for the coffee file to appear.
Here is content of the 2 other files:
the .coffee :
my = 1
alert my
the .map:
{
"version": 3,
"file": "aa.js",
"sourceRoot": "",
"sources": [
"aa.coffee"
],
"names": [],
"mappings": ";AAAA,EAAA,EAAA;;AAAA,CAAA,CAAA,CAAK;;AACL,CADA,CACA,GAAA"
}
Do you have an idea why the source map process doesn't work on chrome dev tools ?
edit: I've now changed my mind on all this and don't use source-map debugging at all. First, it was generally flaky. Second, if I'm not writing JS I should at least be able to read it so I always debug in js.
First, keep in mind that source map debugging is flaky in Chrome right now. A couple things you can try:
Put a debugger statement in your code. I've noticed that the debug is very flaky -- about 10% of the time it just won't stop on breakpoints.
Open the coffee file directly by pressing Ctrl O in the sources pane then place breakpoints or use debugger statements.
Figure out why "sourceRoot": "", is empty. It's possible that that just means that the source file will be in the same directory as the js file (seems likely). My coffee files are in a different directory so they have a sourceRoot entry.
Generate the source maps with grunt or coffeescript. This seems unlikely to have an effect though.
I'm betting #2 will do it.