The new libman in Visual Studio is super simple and lightweight.
But I cannot figure out how to download a directory with it...
I have this config:
{
"version": "1.0",
"defaultProvider": "cdnjs",
"defaultDestination": "lib",
"libraries": [
{
"library": "jquery#1.11.3",
"destination": "lib/_jquery",
"files": [ "jquery.js" ]
},
{
"library": "jqueryui#1.12.1",
"destination": "lib/jqueryui",
"files": [ "jquery-ui.css", "jquery-ui.js", "images" ]
}
]
}
But the images folder in the jqueryui lib doesn't download the images folder.
Also tried images/* and images/*.* to no avail.
If I don't specify any files, then I get the whole lib, including all folders. But that downloads all themes as well.
So how do I just download specific dirs?
There is no way to specify patterns to get the files from a library currently.
Libman just get all the files in the library and builds a dictionary to the file path specified and check if exists or not, unfortunately.
https://github.com/aspnet/LibraryManager/wiki/libman.json-reference#packagesfiles-required-by-some-providers
Related
When a build a conda environment like this
conda create --prefix env python=3.6.5
Some absolute paths appear in some json files in the conda-meta folder. How can I avoid it? I just want to use relative paths here or I just want to hide them completely. Is there a way to achieve this? Are they mandatory? See extracted_package_dir, source or package_tarball_full_path attributes:
{
"arch": "x86_64",
"build": "py36_0",
"build_number": 0,
"channel": "https://repo.anaconda.com/pkgs/main/win-64",
"constrains": [],
"depends": [
"python >=3.6,<3.7.0a0"
],
"extracted_package_dir": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"features": "",
"files": [
"Lib/site-packages/certifi-2019.03.09-py3.6.egg-info",
"Lib/site-packages/certifi/__init__.py",
"Lib/site-packages/certifi/__main__.py",
"Lib/site-packages/certifi/__pycache__/__init__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/__main__.cpython-36.pyc",
"Lib/site-packages/certifi/__pycache__/core.cpython-36.pyc",
"Lib/site-packages/certifi/cacert.pem",
"Lib/site-packages/certifi/core.py"
],
"fn": "certifi-2019.3.9-py36_0.tar.bz2",
"license": "ISC",
"link": {
"source": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0",
"type": 1
},
"md5": "e1faa30cf88c0cd141dfe71e70a9597a",
"name": "certifi",
"package_tarball_full_path": "C:\\Users\\UserName\\AppData\\Local\\conda\\conda\\pkgs\\certifi-2019.3.9-py36_0.tar.bz2",
"paths_data": {
"paths": [
[...]
If I remove the whole folder the environment become useless and I cannot activate it anymore in order to install, update or remove new packages.
I want to do this to encapsulate the environment in one application and I do not want to have my original absolute paths in the computer of the final user.
My Use Case
I am developing an electron app that uses a tornado server (that uses python)
Currently I am using electron-builder to add the environment to the installer and works pretty well, but one drawback is the conda-meta folder I commented above. What I do now is to remove it manually when I want to make an installer.
That will probably break conda. It's not written to treat those as relative paths. If you told us more about your use case, maybe we could help. Are you trying to redistribute an installed environment? Have you see the "constructor" or "conda-pack" projects?
Finally the best solution I found was to ignore the folder when creating the final installer with electron-builder.
So I have applied the directive extraResources to add the conda environment except the folder conda-meta. And I have added the filter "!conda-meta${/*}", the meaning is explained here
Remember that !doNotCopyMe/**/* would match the files in the doNotCopyMe directory, but not the directory itself, so the empty directory would be created. Solution — use macro ${/*}, e.g. !doNotCopyMe${/*}.
The result in the package.json file:
"extraResources": [
{
"from": "../env",
"to": "env",
"filter": [
"**/*",
"!*.pyc",
"!conda-meta${/*}"
]
}
],
I want to use nyc to generate code-coverage. I am building some of my projects into node_modules to use them in other projects. When writing tests I want to test the files inside node_modules and therefore I want to include files from node_modules.
Project-Example-Structure
1. foo (directory)
1.1 bar (directory)
1.1.1 node_modules (directory)
1.1.1.1 someFile.js // I want to include this!
1.1.2 foobar
1.1.2.1 foobar.js // this file works
1.1.3 .nycrc
.nycrc
{
"reporter": [
"html",
"text"
],
"all": true,
"cwd": "../",
"report-dir": "./bar/test-run/coverage",
"include": [
"./bar/**/foobar/*.js",
"./bar/**/node_modules/*.js",
]
}
Execute in terminal
nyc mocha
Explanation
nyc uses the .nycrc. cwd: change-working-directory. I want to be able to include files of parent-directory. Sadly include seems not to be able to use "../".
Inside the include-flag I am specifying which files should be included:
"./bar/foobar/foobar.js" does somehow not work.
But: "./bar/**/foobar/foobar.js" includes foorbar.js.
Expected behaiviour
someFile.js should be included. foorbar.js should be included.
Observed behaiviour
someFile.js is not included. foorbar.js is included.
Environment
MacOS Sierra
nyc 11.8.0
You have to modify your config files with
{
"include": [
"node_modules/**/<fileName>.js"
],
"excludeNodeModules": false
}
I have been recently trying to use the MinGW gcc compiler with Code, and am getting some issues with Intellisense(not breaking, but I find it annoying).
I followed the documentation to edit the path for the c_cpp_properties.json file, but the error continues to pop up and I think I have also found contradictory information.
{
"name": "Win32",
"includePath": [
"${workspaceRoot}"
],
"defines": [
"_DEBUG",
"UNICODE"
],
"intelliSenseMode": "msvc-x64",
"browse": {
"path": [
"${workspaceRoot}",
"C:\\MinGW\\lib\\gcc\\mingw32\\6.3.0\\include\\c++"
],
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": ""
}
}
],
"version": 3
I looked on the github repo for the documentation and found someone had committed a change where ${workspaceRoot} was changed to workspaceFolder in the documentation. However, root seems to be the default for VS code, and I only updated to the new orange logo version this morning.
https://github.com/Microsoft/vscode-docs/commit/fa613d436a53bd9c5a21065cf5fa0f1b350d9bc6
So which is the correct way to get Intellisense working, Folder or Root?
Turning #Marks comment into an answer: ${workspaceRoot} is deprecated, ${workspaceFolder} should be used instead: https://code.visualstudio.com/docs/editor/multi-root-workspaces
See also this description of variables: https://code.visualstudio.com/docs/editor/variables-reference
${workspaceFolder} - the path of the folder opened in VS Code
I'm using the asp.net 5 typescript skeleton. When I bundle the application, inside the "dist" folder, I'm seeing a bunch of html and js files. According to the bundles.js file as in:
"bundles": {
"dist/app-build": {
"includes": [
"[**/*.js]",
"**/*.html!text",
"**/*.css!text"
],
If I'm thinking correctly, I should the the bundled version of those file with an app-build.html and app-build.js, yes. Instead I see all the files basically within the "src" folder.
What is working correctly though is the aurelia.js file is being generated properly from the following:
"dist/aurelia": {
"includes": [
"aurelia-framework",
"aurelia-materialize-bridge",
"aurelia-bootstrapper",
"aurelia-fetch-client",
more stuff here...
I haven't changed the skeleton at all. Just trying to get things to work.
Any ideas what may be going on?
Thank much
I'm not sure I understand your question completely and I'm not using the asp.net version of the skeleton but my Aurelia Typescript app has the following bundle config:
"dist/app-build": {
"includes": [
"[*.js]",
"*.html!text",
"[*/**/*.js]",
"*/**/*.html!text",
"*/**/*.css!text"
]
In my case index.html, app.ts (view root) and main.ts (aurelia config) are located in the 'root' folder src. The rest of my code is located in subdirectories.
Hullo,
I would like to test my app for the turn-by-turn configuration and so I wanted to load my GEOJson file to Xcode. Yet when I open the Routing App Coverage File pulldown and try to select my polygon it appears greyed, like all other documents in my filesystem, for that matter. Should it have some specific form or ending, or what else?
Have you tried accessing the file with another xcode project? I've had issues with XCode project files in the past and have had to re-create the project or completely remove all my resources and add them back in to update the directory references.
I wasn't able to get XCode to find the file either .. but I renamed the file to GeoJSON without any file extension and then ran my app through the Simulator without first associating it to my Scheme as described by the Apple docs. And that worked.
For reference my GeoJSON file contained Denmark e.g.
{
"type": "MultiPolygon",
"coordinates": [
[
[
[
6.592041015625,
58.029833609102994
],
[
13.952880859375,
57.924973963067735
],
[
13.886962890625,
52.89389531877394
],
[
5.910888671875,
53.21087169635909
],
[
6.592041015625,
58.029833609102994
],
[
6.592041015625,
58.029833609102994
],
[
6.592041015625,
58.029833609102994
]
]
]
]
}
I solved the issue by appending the right file ending by trying to upload the file on iTunes connect and receiving a tale-telling error.