I have a set of functions defined in a Code Repository (A). Code Repository A has the following structure with my class objectController defined in 'objectController.ts' :
src
index.ts
objectController.ts
How can I use the functions defined in objectController.ts in another Code Repository (B)?
I would actually recommend working within the same Code Repository where possible, but this may in some cases be unavoidable
Steps for setting up the source repository:
Modify package.json to publish the package properly.
Set a new name field to define what the package name should be in other repos. It might make sense to prefix this with something use case specific to avoid conflicts.
Update the main field to "dist/Functions.bundle.js" and the types field to "src/dist/index.d.ts".
(Optional) Set a description.
Commit the package.json changes and publish a tag on this repository.
Validate that the checks pass.
Steps in the destination repository:
Import your source repository.
Go to Settings > Artifacts.
Click + Add
Select your source repository and import it as a backing repository.
Go to package.json. Under dependencies, add the package name you set in the Source repository above (step 1.1), and set the version to the tag that you published (step 2).
Import any exported classes from your package and use them in your code as normal.
Note : You'll have to restart Code Assist after step (2) above in order to have the newly added package show up properly.
Caveats
All code must live in index.ts in the source repository for this to work.
Unit tests in the destination repository that use the imported package will fail. (This may actually be fixable, but I didn't get it to work)
You need to ensure that you have imported all Ontology objects and relations that the source repository relies on into the destination repository.
I also ran into a typing issues in my destination repository.
Error Message:
Errors:
src/index.ts(6,21): error TS7016: Could not find a declaration file for module '{module_name}'. '{redacted}/repo/functions-typescript/node_modules/{module_name}/dist/Functions.bundle.js' implicitly has an 'any' type.
Try `npm install #types/{module_name}` if it exists or add a new declaration (.d.ts) file containing `declare module '{module_name}';`
Solution:
Create a folder called typings.
Create a file within typings called index.d.ts.
Declare the module as shown below in the file created in (2) index.d.ts.
declare module '{module_name}';
Add the path to the file created in (2)index.d.ts in tsconfig.json under the typeRoots element.
"typeRoots": [
"./typings",
"./node_modules/#types/"
]
Related
I'm a newbie in Angular. I used angular-cli to learn about angular and I found the files tsconfig.json and tsconfig.app.json. Both of these are typescript related and I found this link useful.
But why two such files has been used? Why can't the configurations in these two files be combined in one file? Please help me figure this out.
there is nothing that prevents you from getting rid of the tsconfig.app.json. it's just an additional config file that allows you to adjust your configuration on an app basis. this is e.g. useful when you have multiple apps in the same angular-cli workspace.
you could have the root folder with the tsconfig.json and then a sub folder app-a with a tsconfig.app.json file and another app in the sub-folder app-b with it's own tsconfig.app.json, which contains a variation of the global configuration.
the difference in configuration could e.g. be the output directory outDir or the includes or excludes used.
The difference is that tsconfig.app.json is a file that is related to the Angular App in particular, while tsconfig.json is a more general file that contains general typescript configuration. It's especially useful when you have a micro frontends system, where there are multiple Angular subprojects, each of them with its own tsconfig.app.json configuration. But if you want you could perfectly merge these two files into one, actually you surely noticed that tsconfig.app.json contains the line:
"extends": "./tsconfig.json"
which means that the whole App uses the configuration stated in tsconfig.app.json plus the configuration in tsconfig.json
Just want to add one more point.
It seems the tsconfig.app.json(App specific one) will override the tsconfig.json(global one).
My issue was with the types declaration from node not in scope of my Angular project and I was getting compile errors saying Buffer is not found.
I first added the types declaration in tsconfig.json thinking it will take effect in every app.
But I had to add it to my app-specific tsconfig.app.json file for it to take effect on my app.
I'm using Google Cloud Deployment and I am trying to get external input into my template. Namely, I want to set a metadata variable on my instance (when creating the instance) but provide this value on execution.
I've tried:
gcloud deployment-manager deployments create test-api-backend --config test-api-backend.yaml --properties 'my_value=hello'
Which fails (The properties flag should only be used when passing in a template as your config file.)
I've tried:
my_value=hello gcloud deployment-manager deployments create test-api-backend --config test-api-backend.yaml
And use {{env['my_value']}} but the value isn't picked up.
I guess I could add the property in a .jinja file and re-write this file before I run everything, but it feels like a hack. That, or my idea of passing a variable from shell into Deploy Manager is a hack. I'm honestly not sure.
As the error message indicates, the command line properties can only be used with a template. They are essentially meant to replace the config yaml file.
The easiest thing to do is to just rename your yaml file to a .py or .jinja file. Then use that template as the file in the gcloud command instead of the yaml file.
In that new template file, add any defaults you would like if you don't pass them in on the command line.
For python, something like:
if 'myparam' in context.properties:
valuetouse = context.properities['myparam']
else:
valuetouse = mydefaultvalue
If the template uses another template then you'll also need to create a schema file for the new, top level template so you can do the imports there instead of the yaml file.
See the schema file in this github example.
https://github.com/GoogleCloudPlatform/deploymentmanager-samples/blob/master/examples/v2/igm-updater/ha-service.py.schema
If you want, you can ignore all the properties and just do the imports section.
I am trying to build godoc.org source code in my local to make some changes. My working directory is /Users/Dany/go/src/github.com/golang/gddo. In gddo-server package there several files. One of the go file uses a function from another file which is in the same package but unexported. It is throwing Undefined: <function-name> exception.
Folder is structure is,
golang/gddo/
gddo-server
main.go
crawl.go
How do we use unexported function from the same package in a different file? Could anyone help me with this. Also if anyone has any idea about how to build godoc.org code?
Source files of the same package can refer to identifiers defined in any of the source files without any effort. If they are in the same folder and if they have the same package declaration, you can refer all package-level exported and unexported identifiers as if all would have been defined in one file.
See Spec: Packages:
A package in turn is constructed from one or more source files that together declare constants, types, variables and functions belonging to the package and which are accessible in all files of the same package.
And Spec: Package clause:
A set of files sharing the same PackageName form the implementation of a package. An implementation may require that all source files for a package inhabit the same directory.
One thing to note: your example seems to be the special main package. If you want to run it with go run, you have to enumerate all the source files.
To run your example with go run, navigate to the gddo-server folder and type:
go run background.go browse.go client.go crawl.go graph.go main.go play.go template.go
Or simpler if you first build it. Navigate to the gddo-server folder and type:
go build
This will generate a native executable binary in the same folder. To run it type: gddo-server (on Windows) or ./gddo-server (on Linux).
Or you can install it with go install which will place the result executable binary in your $GOPATH/bin folder.
I want to use BIRT to generate reports against data that comes from a JSON based REST API. How can I import this data?
The process for doing this is described at http://developer.actuate.com/community/forum/?app=blog&blogid=45&showentry=471, but it turns out that there are a few important steps missing. I'll fill in a few blanks here.
The original instructions describe creating a Scripted Data Source, with an "open" script that makes use of the com.actuate.json.JSONParser class. First, it is important to realise that this class is not part of BIRT, and needs to be manually added (along with any dependencies).
The download provided by the original instructions provides the com.actuate.json.JSONParser class, but leaves it up to you to source the dependencies. To make things easier I have reimplemented the JSONParser library in Maven, which will then download and package the dependencies for you. It also includes some bug fixes and enhancements like GZIP compression support. You can get the Maven project from https://github.com/mcasperson/birt-jsonparser, and to build the JSONParser library and package the dependencies, run the command
mvn clean package dependency:copy-dependencies
This will result in the birt-jsonparser-0.0.1-SNAPSHOT.jar file being created in the target directory, and all the dependencies copied into the target\dependency directory. Copy all of these JAR files into the {BIRT_INSTALL}/plugins/org.eclipse.birt.report.viewer_{BIRT_VIEWER_VERSION}/birt/scriptlib directory to allow the JSONParser class to be accessed from within your BIRT report.
If you want to debug your report, these JAR files will also have to be referenced in the Debug profile.
When I use yeoman init angular:allto bootstrap my app, yeoman uses the name of the directory I'm calling it from as the name of the main application .js file. I.e. if I'm running the command in /Users/myusername/dev/projects/my-angular-app, then the file app/scripts/my-angular-app.js is created as the main .js file for the app.
If I simply rename the root directory, then using Yeoman to add routes won't work, as it can no longer find the .js file it created. I've tried adding the name of the app as a parameter when invoking the Yeoman init command, but that doesn't work.
I've tried doing the init command in a directory with the name I want the app to have, and then renaming the directory afterwards. But it seems Yeoman reads the name of that directory every time it's invoked, so after changing the name of the directory, Yeoman is no longer able to create routes for me as it can't find the .js file with the same name as the root directory.
How can I make Yeoman use a different name for the my-angular-app.js file?
There's an open ticket about it, please weigh in your thoughts there.
I am not sure if this is possible but you might want to have a look at the Gruntfile.js and replace all the instances in the config were it is storing the old path and replace it with the new path. I am not sure if that will work as I have never tried but it might based on my understanding of Grunt.
I am like you, I like to have things named the way I want which why I don't use Yeoman even though I would love to (like they say, it is opinionated, just too opinionated for me), I have a few custom built grunt tasks that give me most of the functionality I need (mainly auto compile of SASS/TypeScript, minifying CSS/JS, and concating CSS/JS files).
The issue is with generator-angular.
Currently, the app name is taken from the bower component.json file. If you are using the more recent convention of naming this file bower.json, the app name will fall back to the directory name.
Rename bower.json to component.json until support for the new naming scheme makes it into generator-angular.
It looks like these changes have already been made but have yet to be merged into the master branch: renaming-deprecated-component_json