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
Related
My problem is that the portable version of visual studio code don't load my settings I had copied from the folder %APPDATA%/code/user.
I loaded the .zip data and extracted the folder. I added a data folder into the extracted folder of VS Code. It's in Visual Studio Code\data. In there i copied the folder "user" from %APPDATA%/code/ and renamed the user folder into "user-data". Then I started code and the usersettings are not loaded.
The command .\code.exe --user-directory .\data\user-data won't work.
Is this a bug or did I do something wrong?
In portable mode, the --user-directory command linte option is ignored.
From the documentation:
--user-data-dir <dir>
Specifies the directory that user data is kept in, useful when running as root. Has no effect in Portable Mode.
Instead, use the default location of user data for a portable install and copy your user data to that directory (from a previous comment it seems like you've already done so successfuly).
For anyone wishing to use a different user data directory when in portable mode, symlink-ing the user data folder should be a viable option if on a linux-like platform.
(Trivia: this was at first reported as bug, after which the documentation was updated, rather making it a feature.)
You can simply create a folder called data in the root folder with
VS Code.
After the startup, the files with standard settings will be
created in the data folder.
Then you can just copy the settings from the folder %AppData%\Code\User to the folder data\user-data\User.
To migrate already installed extensions, copy the contents of the %HomePath%\.vscode\extensions folder to the data\extensions folder.
I've developed an extension that reads a directory's package.json file. For the extension to work, you must be inside of a JavaScript file. I'm attempting to test this extension by using a test directory inside of the extension's src directory that houses a package.json file and an index.js file.
My goal is to allow the test to open the directory, open the index.js file and the run the tests there. This way the test directory goes anywhere the extension goes and the tests are predictable based on the package.json file I put into place.
How do I get the tests to open that test directory and run the tests from that specific index.js file?
I figured it out. I had to add the path to the directory into "args" array of the Extension Test object in launch.json.
"args": [
"${workspaceFolder}/src/test/test-directory/",
"${workspaceFolder}/src/test/test-directory/index.js",
"--extensionDevelopmentPath=${workspaceFolder}",
"--extensionTestsPath=${workspaceFolder}/out/test"
]
I was also able to have index.js open up as well. All of which I realized were totally useless in the tests that I were doing. But at least now I know how to do it and maybe someone else will, too.
Also, if you don't add ${workspaceFolder} in front of the directory you are referencing, VS Code assumes you want a new file created. So instead of opening the index.js file that I had available, it was creating a new empty file named index.js.
I'm programming a client side applications using SharePoint Designer 2013.
I want to change to VSCODE since it supports a lot of extensions for some Javascript library like angular, jQuery. And because of the Chrome/Node.js debugger extension.
But when I try to start any Debugger, I got the error:
Unable to create 'launch.json' file inside the '.vscode' folder (Error: UNKNOWN: unknown error, mkdir '\\servername\DavWWWRoot\sitename\Style Library\.vscode').
I get this error because it's impossible to create a folder in SharePoint where the name starts with dot.
So there's a possibility to change the name of this folder or the file location to any directory in my local computer?
No, it's not possible to move/rename that folder. VS code is a tool that bases project management on folder content. So it is essential that the project settings reside in the folder being managed.
You can move the "extensions" folder, but unfortunately not the argv.json (so the ".vscode" will, at least be recreated on vscode launch)
https://github.com/microsoft/vscode/issues/17691#issuecomment-559234574
I hope that'll finally change sometime .
https://github.com/microsoft/vscode/issues/3884
https://github.com/OmniSharp/omnisharp-roslyn/issues/953
I'm learning Aurelia via the TypeScript / ASP.NET Core skeleton navigation app. Everything runs fine in its default state. To test the exported production bundle, I run the Gulp Export task, then publish the app via Visual Studio project publish to a local folder, then replace the published wwwroot folder with the wwwroot folder from within the "export" folder, then use dotnet from the command line to run the app.
Things break if I have any source modules in a subdirectory. For example, I moved the welcome.ts/html component files into "/src/Pages" and adjusted its route moduleId in app.ts accordingly to "./pages/welcome". The unbundled app then still runs up fine, but when I try the exported version, I get a request being made by SystemJS to http://localhost:5000/dist/pages/welcome.js which 404s (as you'd expect).
I can see the contents of the welcome component in the app-build.js file, and the config.js file within the export folder contains the expected file paths, i.e. it has "Pages/welcome...".
I have read this seemingly similar issue:
https://github.com/aurelia/bundler/issues/131
But setting depCache to false made no difference in my case. Why is SystemJS trying to load this module separately from outside of the bundle?
I was able to reproduce this error locally.
Presuming that you have a Windows environment, it will be a case-sensitivity issue.
After renaming [P]ages folder to [p]ages, bundled version works as expected.
On the filesystem there is a [P]ages/welcome.js viewmodel, but [p]ages/welcome has been defined as moduleId.
Unbundled mode: Windows filesystem is case-insensitive, which behaviour can be misleading by loading [P]ages/welcome.js correctly.
Bundled mode:
Based on file path, bundling process embeds[P]ages/welcome.js as [P]ages/welcome module.
But, according to the route config, SystemJS will be looking for [p]ages/welcome module within app-build.js.
My recommendation would be to use lowercase folder/filenames whenever it's possible.
I am trying to automate deployments of a particular project and a bit lost as to who to handle config file as well as user assets.
(Application is based on Zend Framework based btw).
Main application folder is structured as follows:
./app
./config.ini <----- config file
./modules
./controllers
./models
./views
./libs
./public
That config file is where all the configs are stored.
So 'app' folder contains whole bunch of code in PHP and 'public' contains whole bunch of code in JavaScript, HTML/CSS and stuff like that(web accessible basically).
If I follow Capistrano's model, where each package is expanded into it's own folder that is then symlinked to, how do I handle that config.ini file?
What about all the user content that is uploaded into ./public folder?
Thanks!
The Capistrano approach to this is to have a structure like this on your remote server:
releases/
20100901172311/
20101001101232/
[...]
current/ (symlink to current release)
shared/
in the shared directory you include your config file and any user generated content (e.g. shared/files). Then on each deployment, once you've checked out the code you automatically create symlinks from the checkout into your relevant shared directories. E.g.:
releases/20101001101232/public/files -> shared/files
releases/20101001101232/application/configs/config.ini -> shared/config.ini
that way, when a user uploads a file to public/files it is actually being stored in shared/files.