As per WebStorm they require that we debug against a dist directory as specified in:
https://blog.jetbrains.com/webstorm/2015/09/debugging-webpack-applications-in-webstorm/
however, as per Webpack recommended development process, we should be running webpack-dev-server, so its all in memory as in:
webpack-dev-server –inline –progress –colors –display-error-details –display-cached –hot –port=3000
so there is no dist directory, which contridicts examples posted #: https://blog.jetbrains.com/webstorm/2015/09/debugging-webpack-applications-in-webstorm/
Is there a way to have webpack-dev-server use dist dir so WebStorm can be mapped to it so we can use source maps for live debug?
FYI this is the project I am using to test:
https://github.com/ocombe/ng2-webpack
tx
Sean
Currently WebStorm needs the created Bundle + SourceMap from WebPack to analyze it and find the actual Breakpoint.
So in short, you can't debug WebPack applications just with the WebPack DevServer. However you can run the normal WebPack build with file watching in parallel to it: `
As you know, you will have to create a distribution/production bundle with source maps and then use that for debugging in WebStorm. Personally, I run tests with Karma while I have the webpack-dev-server running. Karma tests can be run with the debugger and that usually satisfies any of my debugging needs, while the webpack-dev-server provides my "manual test" to see how I'm doing.
I guess what I'm saying for your case... you can have the dev server running while, at the same time, having some kind of automated build with source maps running at the exact same time which you can run and use the debugger on. This can be intensive though so it depends on your memory and processing power.
I ended up using live-server https://github.com/tapio/live-server and followed this tutorial, worked... https://blog.jetbrains.com/webstorm/2015/09/debugging-webpack-applications-in-webstorm/ (just can't use the built in server in webpack, but that's ok)
I would add that you can put the statement
debugger;
in your javascript/typescript files even in framework files of angular or vue2 like *.vue
So even if your path mappings to URL don't work, it will step anyway.
Related
I have a TypeScript/React web app that uses ParcelJS and I would like to have either a step in the build or a simple way of using a resource file that holds git information.
Not sure if there is something that can generate the git information during the build, I'm using npm to launch parcel.
If parcel can load a resource file and make it accessible that could also work by having properties.
My end goal would be to display version and git commit point in the webapp.
I'm going to assume you're using parcel2 (I'm not sure this would be possible in parcel1).
Parcel2 uses babel to transpile typescript by default (through the #parcel/transformer-babel plugin). The babel configuration for this plugin can be over-ridden by simply including a .babelrc (for configuration relevant to only a subset of the project) or babel.config.json file (for configuration that will apply to the entire project). See this scenario matrix that I made in the process of fixing this bug for details about exactly what babel config files should be picked up by parcel. (The "proposed fixes" are merged into parcel2 as of the latest nightly release).
With the ability to supply your own babel configuration, you should be able to use this babel plugin to inject git repository information into your code.
(Since you're using typescript, you'll also need to make sure to include #babel/preset-typescript or #babel/plugin-transform-typescript in your babel config as well).
Mocha is installed globally on Windows, but cmd shows "mocha is not an internal or external command, nor is it a runnable program or batch file"
Mocha (test framework for Node.js) uses make and on Windows machine, such errors occur a lot. I guess, at the time of execution it's not recognizing the path. So, you can follow any of the 2 below:
1) Install mocha globally(if not done already) so that it works in the regular windows command line:
npm install -g mocha
Then run your tests with mocha path\to\test.js
OR
2) Other way to deal with this is to use Cygwin and ensure that the developer packages for Cygwin are installed.
Read this article, it will help you: https://altamodatech.com/blogs/?p=452
On installation, the location of mocha.cmd is not added to path. If you install globally, as #hemanshu suggests, that location is %APPDATA%\npm. So, you either add that to your path, or (as I do) define an alias; my cmd.exe shortcut loads a script to set the path to things actually useful in the command line, set environment variables, etc, and in there I have this:
#doskey mocha=%APPDATA%\npm\mocha.cmd
I've just started using the Yarn package manager and I downloaded a starter Ionic 2 project.
In this project, we have a lot of help from scripts that compile, minify, lint and bundle our code. All of this is provided by ionic-app-scripts, which has several dependencies which it uses to run commands.
The problem is when I use Yarn to install, the node_modules/.bin/ folder does not contain all the necessary executables, like tslint, which is a dependency of ionic-app-scripts, so it is not directly in my package.json.
The result is that when I use Yarn, ionic-app-scripts doesn't work because it expects that the .bin folder contains a tslint executable!
What can I do? Are the ionic-app-scripts's definitions a problem?
[note]: npm install works, but Yarn is much faster!
This is a known issue, and there's a pull request with more information.
In short, if you want to fix this now, you'll have to explicitly include the packages from which you need binaries in your dependencies.
I had this issue but a different solution.
The solution was from this ticket https://github.com/yarnpkg/yarn/issues/992#issuecomment-318996260
... my workaround is going to file manager, right click on /node_modules main folder, selecting properties, and check-uncheck "read-only". You can do it also using attrib in command line. Then you retry installation and it works.
Our MSBuild definitions build both Debug and Release build configurations. (This is due to the deployment system we use and can't be changed.) The problem is that since we run automated tests, they are run twice, once on each build. Is there any way for me to configure tests to be run only on release build?
We're using VS2010/TFS2010.
In the TFS build definition, under the Process tab, under Automated Tests -> Test Sources -> Test Sources Spec, can you modify the path spec to include the name of the releases folder so that the test binaries from the releases folder only are tested?
Change the spec from:
**\MyApp*Tests.dll
To read:
**\Release\**\MyApp*Tests.dll
It looks like a little tweak to Nick's answer did the trick.
..\Release\**\MyApp*Tests.dll
When building the project from command line using mvn clean install everything builds without any issues.
When running some tests that use precompiled C libraries from IntelliJ, tests fail with java.lang.UnsatisfiedLinkError
I may be completely off here, but does IntelliJ not see the .so file? Is so, how can it be added please?
Shared library fails to load with UnsatisfiedLinkError if:
it's not in the working directory configured in the test run configuration.
it's not in PATH environment (on Mac Terminal and GUI apps have different environment, see this answer). Run IDEA from the Terminal open -a /Applications/IntelliJ\ IDEA\ 12.app/ to make environment the same.
it's not in the location specified using -Djava.library.path VM option.
.so depends on some other library that is not found for any of the 1-3 reasons (or the dependency of that dependency is not found, etc).