webstorm code highlighting and code completion for meteor packages - webstorm

I have configured meteor on webstorm and I can see code highlighting and code completion for meteor, but when I add new packages (for example: aldeed:collection2), code highlighting and code completion doesnt work for new packages. How can I make sure that code highlighting and completion also work for new and installed packages.
Regards, Chidan

You should open '.meteor/packages' file and run 'Import packages as library' action (the action will be shown)
Related issue: https://youtrack.jetbrains.com/issue/WEB-17503

Related

Vue gives me a warning about uncommited changes

so I just created a new vue project with vuecli. I played around a bit and then wanted to add a new plugin using vue add <plugin>. Now I get the following warning:
There are uncommited changes in the current repository, it's
recommended to commit or stash them first.
What's that about? Why does this error message use this specific terminology? I'm not using any versioning system, since I'm just playing around and even if I would - that warning would still confuse me. Does vue-cli use some kind of internal versioning system?
I realise this is 6months+ old, but I ran into the same issue.
I am using vue-cli inside MS Studio Code. It appears that Code has a "Source Control" support which (for me) is using git. I didn't configure this directly - I assume that Code found git when it installed and enabled it for me.
I believe that vue-cli detects any uncommitted changes (based on this) in the underlying source code control mechanism.
For me - using MS Studio Code > Source Control (as per picture attached) allowed changes to be staged and vue-cli install to proceed without the warning.
Edit:
It appears (for me) that vue is adding the git integration on project creation - below is default from vue ui. Which I believe is where vue-cli is detecting unstaged changes.

How to do Coverage exports for vscode extensions

I have seen a lot of tutorials how to make vscode extensions. Like:
https://code.visualstudio.com/docs/extensions/testing-extensions
And there is many tutorials how to do coverage exports, there many ways how to do it, but I didn't seen good examples which would follow the examples from their docs and work with vscode extensions (they need the extensionHost instead of nodejs).
I have all the tests written in the mocha which is bundled in the vscode as proposed by their documents.
I tried to experiment and I'm stuck, are there any hints or directions where I could continue and get my process working again?
The answer which worked is in the comments to my original question. But to simplify and boil down what had to be done, and what steps I did personally. Not all steps are really essential and required, but these steps made it pretty convient:
installed istanbul, istanbul-coveralls, gulp, gulp-json-editor, coveralls to my package as the DEV dependencies
included the MS supplied istanbul test runner for vscode extension testing into my tests
modified the tests to run an istanbul runner instead of mocha runner directly (the tests itself could stay as they are).
attached reference to the istanbul runner now I had to read the coverconfig.json to know how to do the coverage itself (what parts to ignore, where is source, where to output results, what formats the results should be etc...).
added coverage to gitignore and to vscode project as so they will not annoy me in the UI and will not polute the repo.
added few visual studio launchers/tasks to make it easier for me to trigger them from the UI
installed vscode plugin to display the coverage in the gutters: https://marketplace.visualstudio.com/items?itemName=ryanluker.vscode-coverage-gutters and then added to my project settings the "lcov.path": [ "coverage/lcov.info" ] (or whatever location you will have the line coverage) so the plugin can read and show the coverage directly in the UI.
setup gulp to delete old coverage results and start new ones on each run
added npm scripts for regular tests and for the coverage variant
changed travis steps so the coverage variant is running now instead of the generic non-coverage one. Added script step so the coveralls module is run and broadcasts the results from the coverage/lcov.info to the https://coveralls.io/ website. (i think signing in and doing the first-time setup is required to make it work on their website)
Now on each commit travis will do the work by itself and I can use coveralls banner inside my readme to give quick glipse how well is my coverage. And you can use gulp to watch it for changes and build/test locally and have fast feedback in the UI what lines were covered by your tests.
The setup is similar to the listed links:
https://github.com/Microsoft/vscode-mssql
https://github.com/kenhowardpdx/vscode-gist/pull/10

How can I get source maps to work when running tests using ember-qunit for an ember app built on ember-cli

I have an Ember app built using ember-cli and I'm writing my tests using the ember-qunit testing adapter and running them in the browser using testem as instructed in the ember-cli documentation. Although debugging in Google Chrome works fine when I'm interesting with my app, I am unable to use many debugging features such as breakpoints when running my tests.
I often run into a problem that my tests fail despite my actual app seeming to work properly, and to investigate the problem I would like to step through code while my tests are running.
But when I step into code that appears in vendor.js I just just see the following contents in my vendor.js:
// Please wait a bit.
// Compiled script is not shown while source map is being loaded!
These two lines are lines 6 & 7 of the file. The lines before this are blank, and these two lines are the last lines in the file. The debugger has the first line of the file highlighted as if that's the current location in the source, but it cannot show the source for some reason.
I can proceed to step through the code, but I can't see anything.
However, if I find vendor.js in the list of sources in the developer tools sources file list then it opens as a separate source tab and I can see all my code. At this point I have two tabs labeled vendor.js, one with all my vendor assets and one with just those line quoted above.
I am guessing that there is something different between how my tests are served and how my app is served in the development environment that is confusing Chrome.
I am using the following versions of things:
ember 1.9.1
ember-data 1.0.0-beta.14.1
ember-cli 0.1.9
qunit 1.17.1
ember-qunit 0.2.0
testem 0.6.33
Although I've poked around a bunch I don't really have any leads on where the problem is stemming from. Perhaps it's related to how testem is running the tests? Or could it be something that gets included in my tests has a messed up source map?
I appreciate any help or ideas.
I'm on ember-cli 0.2.2.
I ran across this problem as well and found this Chrome issue with processing sourcemaps.
People commenting on the issue suggest using the Chrome Canary build for now:
I'm currently using the Canary build to put breakpoints in and debug my ember code.
Get it here: https://www.google.com/chrome/browser/canary.html

Can't open clojure the project in Intellij IDEA with La Clojure

I was going through this tutorial
http://wiki.jetbrains.net/intellij/Getting_started_with_La_Clojure and I got stuck here
http://wiki.jetbrains.net/intellij/Getting_started_with_La_Clojure#Opening_project_in_IntelliJ_IDEA. I don't know way but 'open project' dialog does show the file 'project.clj'. So I'm not able open the clojure project. (And also I don't know how to create new one)
Is this bug of IDEA/La clojure or I did something wrong?
To open/import clj projects, you need to have the Leiningen plugin installed.
Unfortunately, the latest official release of the lein plugin for intellij doesn't work well with Intellij13 (crashed my idea on load every time until removed manually).
I'm guessing that because of Cursive there wasn't a newer release even though the latest version of the plugin on github does work.
I followed the instructions on the lein plugin's git page to create a plugin bundle from the latest version: https://github.com/derkork/intellij-leiningen-plugin
Assuming you're using Intellij13, creating the bundle yourself and then installing it from disk will enable you to open clj project files.

getting started with SBT for lift

I am a complete newbie to SBT and scala world. I wanna create a lift application and while exploring on how to do it i stumbled everywhere that i must use SBT. So i went to the github wiki page and followed the instructions for windows. I downloaded the jar given there and created sbt.bat and put both the files in c:\sbt and added it to my path. Then i went c:\liftprojects and typed sbt.
It did something but as given everywhere i expected a wizard of some sort which will ask me what kind of project i wanna build and stuff and generate the directory structure just like mvn:archetype:generate but it didnt do anything. It just ran some downloads and created two dirs
project
boot
blah
target
blah
target
scala 2.8.1
blah
in github wiki it says sbt follows maven bir structure but i cannot see it here.
Am i doin something the wrong way. Im stuck on this. All i need is to know how to create a lift app or a scala project.
To get started with Lift 2.4 my recommendation is to clone the examples repository
git clone https://github.com/lift/lift_24_sbt
Then you can use one of the project templates in that repo, with both 2.8 and 2.9 Scala versions. For example, a good way to start with Lift is using the basic project (with Scala 2.8.1 in this example)
cd lift_24_sbt/scala_28/lift_basic/
Start sbt by typing
./sbt
On Windows use sbt.bat. Inside the sbt console, type
update
jetty-run
Open a web browser and point it to http://localhost:8080 to open the Lift application. To stop the application server, simply type jetty-stop.
You can use this template project, or the other templates in that repo, as a starting point for your applications.
Lift wiki contains a lot of useful information. Specifically, you can follow the instructions getting started section here.