my polymer.json
{
"entrypoint": "index.html",
"shell": "src/boo-blogger/boo-blogger.js",
"sources": [
"images/*",
"fonts/*"
],
"extraDependencies": [
"manifest.json",
"node_modules/#webcomponents/webcomponentsjs/*.js",
"node_modules/web-animations-js/web-animations-next-lite.min.js",
"node_modules/#webcomponents/webcomponentsjs/bundles/*.js"
],
"builds": [
{
"name": "es6",
"bundle": true,
"browserCapabilities": [
"es2015",
"modules"
],
"js": {
"minify": true,
"transformModulesToAmd": true
},
"html": {
"minify": true
},
"css": {
"minify": true
},
"addServiceWorker": true
}
],
"npm": true,
"lint": {
"rules": [
"polymer-3"
]
}
}
I got the problem
article-list.js:5 Uncaught (in promise) TypeError: _booBlogger.html$1 is not a function
article-list.js imported dynamic by routing. So I tried to attempt some build option differently to build. I found when I build without bundle, built code can work. I don't know why my code can not bundle by polymer build. if anyone is curious the problem and need completely source code. contact me
tools summary
system: ubuntu 16.04
polymer: 1.7.7
node: 10.1.0
In your polymer.json you need to add:
"fragments": [
"src/article-list.js"
],
I think you forgot to add article-list.js to your sources. As it is written in docs you have to include your dynamically imported modules to "sources" in polymer.json. See https://polymer-library.polymer-project.org/3.0/docs/apps/build-for-production#dynamic
Related
I have an Angular flavoured Nativescript project, which must be tested with "vanila" Jasmine, in a browser (so not in mobile) with ng test.
By default, with "naked" tests, it works. But the problem is, if I try to test/import anything, that has a ".tns" alternative, in some cases it loads that, and the build fails.
My problem is similar to this thread but there were no good solution described there.
So for instance:
I have two files:
app.component.tns.ts
app.component.ts
and I try to import it for testing in app.component.spec.ts:
import {AppComponent} from "#src/app/app.component";
it loads the .tns. file, and the build fails, as it cannot load the mobile-specific libraries.
ERROR in ./src/app/app.component.tns.ts
Module not found: Error: Can't resolve 'nativescript-ui-sidedrawer' in '/home/..../src/app'
resolve 'nativescript-ui-sidedrawer' in '/home/...../src/app'
Parsed request is a module
using description file: /home/...../src/package.json (relative path: ./app)
Field 'browser' doesn't contain a valid alias configuration
resolve as module
...
# ./src/app/app.component.tns.ts 25:35-72
# ./src/app/app.module.spec.ts
# ./src sync \.spec\.ts$
# ./src/test.ts
is there any solution to "remove" the .tns. files, just as if I were running a simple ng serve?
update: My tsconfig.spec.json should exclude these files, but it does not work either ...
"exclude": [
"**/*.tns.ts",
"**/*.android.ts",
"**/*.ios.ts"
]
}
it seems the problem was with tsconfig.json. Specificly this part:
"compilerOptions": {
...
"paths": {
"#src/*": [
"src/*.android.ts",
"src/*.ios.ts",
"src/*.tns.ts",
"src/*.web.ts",
"src/*.ts"
]
},
As this was extended by the tsconfig.spec.json.
I modified the tsconfig.spec.json to this:
{
"compilerOptions": {
"target": "es5",
"declaration": false,
"module": "esnext",
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"skipLibCheck": true,
"typeRoots": [
"node_modules/#types"
],
"lib": [
"es2017",
"dom",
"es6",
"es2015.iterable"
],
"baseUrl": ".",
"resolveJsonModule": true,
"esModuleInterop": true,
"paths": {
"#src/*": [
"src/*.ts"
]
},
"outDir": "../out-tsc/spec",
"types": [
"jasmine",
"node"
]
},
"files": [
"src/test.ts",
"src/polyfills.ts"
],
"include": [
"**/*.spec.ts",
"**/*.d.ts"
],
"exclude": [
"**/*.tns.ts",
"**/*.android.ts",
"**/*.ios.ts"
]
}
and now the tests run, and the correct components are imported.
I am writing a nodejs addon that depends on OpenGL (glfw). It compiles successfully but when I try and use it in node I get the error The specified module could not be found.
This is the problematic part of the addon C++ code:
#include <glfw/glfw3.h>
if(glfwInit()) {
printf("glfw init success");
}
else {
printf("glfw init failed");
}
With this in the addon, it compiles but causes the error in node. Without this it compiles and runs without issue.
Here is my binding.gyp:
{
"targets": [
{
"target_name": "engine",
"sources": [
"addon/addon.cc"
],
"libraries": [
"<(module_root_dir)/addon/lib/gl/glfw3dll.lib"
],
"include_dirs": [
"addon/lib",
"<!#(node -p \"require('node-addon-api').include\")"
],
'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ],
}
]
}
And the addon file structure:
addon
lib
glfw
glfw3.dll
glfw3.h
glfw3.lib
glfw3dll.lib
glfw3native.h
opengl32.lib
addon.cc
Edit:
New binding.gyp:
{
"targets": [
{
"target_name": "engine",
"sources": [
"addon/addon.cc"
],
"libraries": [
"-lglfw3dll",
"-lopengl32",
"-L<module_root_dir)/lib/glfw",
"-Wl,-rpath,\$$ORIGIN/../../lib",
],
"include_dirs": [
"addon/lib",
'<!#(node -p "require(\'node-addon-api\').include")'
],
'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ],
}
]
}
I'm not sure this is your issue but it can be a bit tricky to convince the loader to load a specific library in a local directory. I added this section to my the targets array in binding.gyp.
The trick is to tell the linker look for the library relative to $ORIGIN(where the addon is). Because the addon is in build/Release then $ORIGIN is build/Release and ../../ gets you back to the module root.
It just took trial and error to find the right way to specify $ORIGIN via binding.gyp and the linker's quoting rules. \$$ORIGIN resulted in $ORIGIN being embedded in the node addon.
'conditions': [
['OS in "linux"', {
# includes reference glfw3dll/glfw3dll.h, so
'include_dirs': [
'<!#(node -p "require(\'node-addon-api\').include")',
'<(module_root_dir)/'
],
'libraries': [
'-lglfw3dll',
'-L<(module_root_dir)/dir-for-glfw3dll/',
'-Wl,-rpath-link,<(module_root_dir)/dir-for-glfw3dll/',
'-Wl,-rpath,\$$ORIGIN/../../dir-for-glfw3dll/'
],
}]
]
(I changed the name of my file to your file and put it in a directory directly under the module_root_dir.)
I managed to get it working with this binding.gyp file:
{
"targets": [
{
"target_name": "engine",
"sources": [
"addon/addon.cc"
],
"libraries": [
"legacy_stdio_definitions.lib",
"msvcrt.lib",
"msvcmrt.lib",
"<(module_root_dir)/addon/lib/glfw/opengl32.lib",
"<(module_root_dir)/addon/lib/glfw/glfw3.lib"
],
"include_dirs": [
"addon/lib",
'<!#(node -p "require(\'node-addon-api\').include")',
],
'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ]
}
]
}
Just in case someone else has the same issue and ends up here. The libraries that are required by the addon needs to be within reach on runtime, even if the linker managed to find it.
For example if this is on Windows, and you linked with foo.lib during your build/link, during runtime, foo.dll should be either in the same folder (for me it worked in the same folder as .node) or in a folder in the path. Otherwise it wont be loaded and this error will be thrown. Very unexplanatory error in my opinion.
Also, keeping the libraries in the same folder as the .node helps with segregating the different arch builds & dependancies (x86, x64 etc).
I am trying to get Chutzpah and Jasmine working together in visual studio, my end goal is to get unit tests running with TeamCity integration.
On save, all of the typescript code generates a single .js file. This also causes Chutzpah to run my tests, so far so good.
My issue is Chutzpah reports 0 passed, 0 failed and 0 errors. The Jasmine html file that is generated lists out all of my tests correctly but Chutzpa doesn't seem to receive any information back from Jasmine.
Highlights of a trace log:
Trying to build test context for c:\.....\test.ts
Building test context for c:\.....\test.ts
...framework dependencies / other ok looking things... (~15 lines)
Finished building test context for c:\.....\test.ts
Warning: 0 : Message:Chutzpah determined generated .js files are missing but the compile
mode is External so Chutzpah can't compile them. Test results may be wrong.
Then it starts Phantom js and logs loading / receiving resources. My test.ts file is not one of the recources listed but the site-wide .js is (I checked the site-wide file and my tests are being appended to it).
Finished test run for c:\......\test.ts in Discovery mode
Cleaning up test context for c:\......\test.ts
Chutzpah run finished with 0 passed, 0 failed and 0 errors
Chutzpah.json file cache cleared
End Test Adapter Discover Tests
chutzpah.json
{
"Framework": "jasmine",
"EnableTestFileBatching": true,
"Compile": {
"Mode": "External",
"Extensions": [ ".ts" ],
"ExtensionsWithNoOutput": [ ".d.ts" ],
"Paths": [
{
"OutputPath": "../SiteWide.js",
"SourcePath": "Views"
}
]
},
"References": [
{
"Path": "../knockout-3.4.2.js",
"IsTestFrameworkFile": true
}
],
"Tests": [
{
"Includes": [ "*.ts" ],
"Path": "../Tests/Views"
}
],
"EnableTracing": true,
"TraceFilePath": "./trace.log"
}
tests.ts
describe('configuring unit tests for typescript!', () => {
it('this should pass', () => {
expect(1).toBe(1);
});
it('this should fail', () => {
expect(1).toBe(0);
});
});
There are a few things I'm suspicious of (the missing .js files line from the trace - but that might just be caused by my single js file compilation step?)
Maybe I'm missing references to jasmine in my chutzpah.json?
I'm at a loss for why the Jasmine tests work, but Chutzpah doesn't report back.
Maybe late...
But something like this in chutzpah.json would help.
{
"Framework": "jasmine",
"Compile": {
"Mode": "External",
"Extensions": [ "*.ts" ],
"ExtensionsWithNoOutput": [ "*.d.ts" ]
},
"References": [
{ "Path": "node_modules/promise-polyfill/dist", "Include": "*.js", "Exclude": "*.d.ts" },
{ "Path": "node_modules/systemjs/dist", "Include": "*.js", "Exclude": "*.d.ts" }
],
"Tests": [
{ "Path": "unittests", "Includes": [ "*.spec.ts" ], "Excludes": [ "*.d.ts" ], "ExpandReferenceComments": "true" }
]
}
Having your system related files is important in the references. Also you can try "*.spec.js" in the Tests section
I am using Chutzpah Version 3.2.3 with Typescript and nUnit.
I am able to successfully run the unit tests. But when i do cod coverage for the same unit tests i get
Error: Timeout occurred when executing test file
I have no clue where to even start looking to fix it. I have been banging my head about this issue for a day now, Any leads are highly appreciated.
Below is my chutzpah.json
{
"Framework": "qunit",
"TestHarnessLocationMode": "Custom",
"TestHarnessDirectory": "../example.exampleTest.Client.Excel.Web/App",
"Compile": {
"Mode": "External",
"Extensions": [ ".ts" ],
"ExtensionsWithNoOutput": [ ".d.ts" ],
"SourceDirectory": "../../Example.exampleTest/",
"OutDirectory": "../../Example.exampleTest/"
}
}
I was able to resolve the issue by being specific about which files to include in code coverage and which files to exclude. Below is my updated chutzpah.json
{
"Framework": "qunit",
"EnableCodeCoverage ": "true",
"CodeCoverageIncludes": [
"*Orchestrator*",
"*Transformer*",
"*Processor*"
],
"CodeCoverageExcludes": [
"*\\Example.Example.Client.Excel.Web\\App\\Workstreams\\AX-AX\\*",
"*\\Example.Example.Client.Excel.Web\\App\\Workstreams\\CS\\v1.0\\CS-ICS\\*",
"*\\Example.Example.Client.Excel.Web\\App\\Workstreams\\CAD-CAD\\*",
"*\\Example.Example.Client.Excel.Web\\App\\AddInModules\\*",
"*\\Example.Example.Client.Excel.Web\\Scripts\\*",
"*\\Example.Example.Client.Excel.Web\\Mocks\\*"
],
"TestFileTimeout":"200000",
"Compile": {
"Mode": "External",
"Extensions": [ ".ts" ],
"ExtensionsWithNoOutput": [ ".d.ts" ],
"SourceDirectory": "../../Example.Example/",
"OutDirectory": "../../Example.Example/"
}
}
I am trying to create a simple cross platform C++ project with gyp. Currently I'm just trying this on a mac - but would like to get it to build for windows, Linux, ios and android eventually.
HEre is the simple gyp file that I'm using.
I would like to be able to use ninja as well as xcode/msvc projects from this gyp.
I know that I need to be able to add
-std=c++11 and -libstdc++ to the commandline for clang, but right now I only see the generated build files using g++ instead of clang.
This is my gyp file.
{
'targets': [
{
'target_name': 'libtest',
'product_name': 'test',
'type': 'static_library',
'sources': [
'./src/lib.cpp',
],
'include_dirs': [
'include',
],
},
{
'target_name': 'testapp',
'type': 'executable',
'sources': [
'./test/test.cpp',
],
'include_dirs': [
'src',
],
'dependencies': [
'libtest'
],
},
],
}
I've sort of figured out this to a certain extent. At lesast I got it working on the mac for a makefile build ( not ninja which was my original hope).
First I had to get gyp to use clang instead of g++ , to do this I had to add a make_global_settings to the gyp file as so. This doesn't seem like a good plan for a crossplatform build. I was also able to set these with environment variables, I'm guessing I can probably do something with conditions to make this specific to the mac.
'make_global_settings': [
['CXX','/usr/bin/clang++'],
['LINK','/usr/bin/clang++'],
],
'targets':
[
......
The other thing I had to do was add an xcode_settings dictionary with OTHER_CPLUSPLUSFLAGS and OTHER_LDFLAGS depending on the target type. Full example below.
{
'make_global_settings': [
['CXX','/usr/bin/clang++'],
['LINK','/usr/bin/clang++'],
],
'targets': [
{
'target_name': 'mylib',
'product_name': 'mylib',
'type': 'static_library',
'sources': [
'src/implementation.cc',
],
'include_dirs': [
'include',
],
'conditions': [
[ 'OS=="mac"', {
'xcode_settings': {
'OTHER_CPLUSPLUSFLAGS' : ['-stdlib=libc++'],
},
}],
],
},
{
'target_name': 'myapp',
'type': 'executable',
'sources': [
'./bin/myapp.cc',
],
'conditions': [
[ 'OS=="mac"', {
'xcode_settings': {
'OTHER_CPLUSPLUSFLAGS' : ['-std=c++11','-stdlib=libc++'],
'OTHER_LDFLAGS': ['-stdlib=libc++'],
},
}],
],
'include_dirs': [
'include',
],
'dependencies': [
'mylib'
],
},
],
}
So I just tried this on the clang++ 6 OSX 10.10 and I ran into the same problem that drewish hit.
Adding -mmacosx-version-min=10.7 to the OTHER_CPLUSPLUSFLAGS and OTHER_LDFLAGS arrays fixed the issue.
EDIT
An even better way that I found to fix this is to add "MACOSX_DEPLOYMENT_TARGET": "10.7" into the xcode_settings array. This will override any defaults that Node sets in its common.gypi file.
So it should look something like this
{
'targets': [
{
'target_name': 'myApp',
'sources': [ 'myApp.cc' ]
'conditions': [
['OS=="mac"', {
'xcode_settings': {
'MACOSX_DEPLOYMENT_TARGET': '10.7'
}
}]
]
}
]
}
johnhaley81's solution is really the simplest one to get this working (at least on OSX), however I had to add a few more settings:
"conditions": [
[ 'OS=="mac"', {
"xcode_settings": {
'MACOSX_DEPLOYMENT_TARGET': '10.9',
"CLANG_CXX_LIBRARY": "libc++",
"GCC_ENABLE_CPP_RTTI": "YES",
"GCC_ENABLE_CPP_EXCEPTIONS": "YES"
},
}],
],
As you can see, you can directly use the name/value pairs from an XCode project here. Pretty handy.
The previous answers were helpful, but all that must actually be added to xcode_settings are 'MACOSX_DEPLOYMENT_TARGET': '10.7' and 'CLANG_CXX_LIBRARY': 'libc++'
{
'targets': [
{
'target_name': 'myApp',
'sources': [ 'myApp.cc' ]
'conditions': [
['OS=="mac"', {
'xcode_settings': {
'MACOSX_DEPLOYMENT_TARGET': '10.7',
'CLANG_CXX_LIBRARY': 'libc++'
}
}]
]
}
]
}
Specifically, the option 'CLANG_CXX_LIBRARY': 'libc++' is what's getting us what we want. If you add this option without 'MACOSX_DEPLOYMENT_TARGET': '10.7' then you might see the following error:
clang: error: invalid deployment target for -stdlib=libc++ (requires OS X 10.7 or later)
This error indicates that 10.7 is a more appropriate value than 10.9 for MACOSX_DEPLOYMENT_TARGET if you're interested in compatibility.