I tried MongoDB Stitch earlier this year, and at the time it did not feel like a finished product (for example, apps cannot be renamed). I am giving it another go, and this time I am interested to see how I could create automated tests for my Stitch functions using Jest (this also may not be straightforward).
I have noticed that the Functions section has a DependenciesBeta tab. Here one may zip up NPM modules in a tarball, and they will become available in the Stitch JS environment. I wonder if I could use this to circumvent the import difficulties I am experiencing with the functions system - instead I could make (untested) lightweight calls from Functions to Dependencies, and then just test the dependencies.
However, I want to be able to import my app automatically using the console command, to deploy automatically in a CI pipeline. For this to work, import/export would need to include dependencies as well, but the file-format docs do not mention dependencies. Is there any support for syncing dependencies from the console, as part of an app import?
Is there any support for syncing dependencies from the console, as part of an app import?
Yes, you can import dependencies using mongodb-stitch-cli (v1.10+).
To upload external dependencies:
First need a local node_modules folder containing at least one Node.js package. If the node_modules folder does not already exist, npm install <package> will automatically creates it.
Next you need to package them up in an archive so you can upload them to Stitch:
tar -czf node_modules.tgz node_modules/
Other supported formats/extensions are : .zip, .tar, .gz, .tgz
Next you can place the archive into the functions directory in the application file schema. i.e.
├── functions/
│ └── <function name>/
│ ├── config.json
│ └── source.js
│ └── node_modules.tgz
Execute the import command with --include-dependencies, i.e:
stitch-cli import --app-id <APP_ID> --path ./your_app --include-dependencies
Creating draft for app...
Draft created successfully...
Importing app...
Deploying app...
Deploying app...
Done.
Importing hosting assets...
Done.
Please note that currently stitch-cli does not support export for dependencies yet.
See also Stitch: Upload External Dependencies to upload from the UI.
Related
This semester, I began learning Vue. Our first "assignment" for the Vue phase was to follow along with, and complete, the instruction provided by a YouTube video from Traversy Media. This video was great to follow, evident that I was able to complete its objective with little difficulty. However, I don't feel that I quite understand the relevance of each file within a Vue project, such as index.js, index.html, *.vue.
I've found a few videos which create a component and then utilize that component. However, I feel completely lost when downloading a component, specifically: 'Vue-Accordion' from github to use as my navigation in conjunction with vue-router. The vue-accordion instructions simply state to add specific code, but doesn't say to which file I should add this code.
I've hacked at it by guessing/assuming a file that I figured relevant to the task, such as app.vue, index.js, and index.html... to no avail. Certainly, I think that a better understanding of a Vue Project's file-structure/hierarchy could give me a better feel in knowing exactly what files are relevant to any task-at-hand that I may have.
Alright so schools in session (sorry if I explain too basic stuff at times, just trying to be thorough).
Here's the basic structure for a Vue project using vue init webpack-simple my-project:
src/
assets/
logo.png
App.vue
main.js
.babelrc
.gitignore
index.html
package.json
README.md
webpack.config.js
The src folder contains all the source files of your project.
The src/assets folder contains all your assets, primarily images.
App.vue is the first "view" of your app.
main.js is the main script of your project where you configure and run Vue. This is where you load anything that should exist in the global scope of your app.
.babelrc configures how the babel tool should syntax check your code.
.gitignore tells Git to ignore certain files from committing.
index.html is the page that's sent to the clients browser. This is where we load the main.js file and put any and all meta data you need (unless you use e.g. vue-meta to handle it there instead). Note that <div id="app"> html tag, this is where all your Vue files get mounted to.
package.json is our npm configuration file. When you run e.g. npm install --save component-from-npm-name it's saved here so you can just run npm install later to get all the dependencies of your project.
README.md is a documentation file in the Markdown language format. It's displayed as the frontpage of your project on e.g. Github or Gitlab.
webpack.config.js is a Node.js file that is responsible for running Webpack on your project. Vue can be used without Webpack but I don't recommend it. You can run node webpack.config.js directly to build your project. This file is your build script, you configured this to handle the build process of your project.
So, armed with this information, lets get to your question.
How do you load a component in Vue.js?
Run npm install --save vue-accordion (note that while the source code is hosted on Github, the package is downloaded from here: https://www.npmjs.com/package/vue-accordion)
In your index.js file, which is responsible for loading things to your Vue app in the global context, you do as the Github page tells you and first import {vueAccordion} from 'vue-accordion', then run Vue.component('vue-accordion', vueAccordion) to register it in the global context.
That's all there is to it. index.jsis your entry point for your Vue app, while webpack.config.js is your build script.
There is however an alternative solution to loading components. In the previous variant we loaded it in index.js to load it in the global context, i.e. you can use the component now anywhere in your app, but what if you only want to load it on an as-is-needed basis (you'd wanna do this for performance reasons)?
Well, in your App.vue file you have a <script> tag where you can configure things in just that Vue component (all .vue files are Vue components, even if you call them routes, pages, views or whatever to indicated their purpose). In order to load a component not in the global context, but the component context, you'd do the following in App.vue:
<script>
import Accordion from 'vue-accordion';
export default {
components: {
'vue-accordion': Accordion
}
</script>
Tips...
This is just one setup for a Vue project. A Vue project can be as simple as just loading Vue as a script to your static index.html file, then you can have a much more annoying setup with regular javascript files, but that's dumb and inefficient. So, a proper project has a Node.js file to run Webpack. Depending on how you configure Webpack your project can act quite differently from any other Webpack project.
Read up more on how Webpack works so you can have a project structure that makes sense for you.
Take a look at Nuxt, it's essentially a collection of other projects (primarily Vue and Webpack) that simplifies the making of a powerful Vue project. You can sit and set up your own Vue project and all the tools yourself and get the same result, but Nuxt makes it simpler for you to do.
To install a specific GitHub repository as a node dependency.
Actually, it doesn't matter if it is a dependency for Vue or React
it is related to setting in the package.json dependency from a GitHub source.
You need to modify your package.json file. In the dependencies section, add the package name as the property name and, as a value, the username of the repository in GitHub and the repository directory.
e.g
"dependencies": {
"#zeratulmdq/vue-accordion": "zeratulmdq/vue-accordion"
}
and then to import the component
import VueAccordion "#zeratulmdq/vue-accordion"
It is not related to your desired repository, but just in case the selected repository package.json file does not point to the correct main property, it will not load the component, so you will need to point to the specific component file to import, e.g:
import VueAccordion "#zeratulmdq/vue-accordion/src/index.js"
or
import VueAccordion "#zeratulmdq/vue-accordion/src/App.vue"
When adding https://www.npmjs.com/package/material-design-icons as a dependency to my Node application, cf push fails with Disk quota exceeded when running npm install. Since the complete application including node_modules has about 100 MB (way below the limit of 1 GB), I assume it might have to do with the fact that material-design-icons has about 86'000 files (for whatever reason).
Is there any workaround for this?
Another solution is to ignore the node_modules directory using the .cfignore file (the same concept as the .gitignore file). The files described in the .cfignore aren't uploaded to Cloud Foundry when you push your app.
You can find more about .cfignore here: https://docs.developer.swisscom.com/apps/deploy-apps/prepare-to-deploy.html#exclude
The solution is to delete the directory node_modules from your app directory before to push it. The description of the needed modules must be in the file package.json under dependencies. I tested a simple express app adding the material-design-icons module. Pushing the application without the content of the directory node_modules works, since in staging the modules are downloaded and added to the application.
The solution is to delete the directory node_modules from your app directory before to push it. The description of the needed modules must be in the file package.json under dependencies. I tested a simple express app adding the material-design-icons module. Pushing the application without the content of the directory node_modules works, since in staging the modules are downloaded and added to the application.
The solution with .cfignore should work. You might need to delete and re-push your app though, since Cloud Foundry caches some files and the container might be filled with these cached files. If you delete and re-push the app, you're getting a clean container from scratch which might solve your problem.
I have faced the same problem. I solved it by doing the following:
Using .cfignore
Specifying the update nodejs in package.json
Using the latest buildpack
I use broccoli-less in my ember cli project and would like to use an addon (ember-cli-materialize), which uses broccoli-sass.
After installing the addon, i get: File to read not found or unreadable ../app.scss, because i also have an app.less file in my styles dir.
As i understand, this commit Allow multiple preprocessors per type should make it possible, although i might be missing something. Has anyone managed to use ember-cli with multiple preprocessors, and what changes is needed?
Ember-cli version: 1.13.1
Ember version: 1.12.0
Thanks
I know your circumstance is different than mine but this may help others or spur a better solution. I was added to a dev team to polish up an app already styled using LESS. I favor SASS and tried to use ember-cli-sass alongside ember-cli-less without any success.
You may want to look further into Ember-Cli's add.import
By adding your input configurations to ember-cli-build.js with the above, you can leverage either your bower-components directory (if used) or vendor directory, to import a compiled CSS doc (from Sass source files) that will build alongside the project quite nicely with a simple sass --watch <input:output> command.
The LESS files are ultimately compiled to app.css, and your SASS files to vendor.css (make sure you link to the stylesheet in your index page/template).
I've compiled Goauth so that I can use OAuth in my Go Google App Engine project. Where do I put the goauth.a file so that I can both use it in the project, and have it available when deploying to the GAE servers? I can get it working locally if I put it in a subfolder of $GOROOT/pkg, but then it can't be found when compiling at deployment time.
GoClipse sets up a project with lots of folders, I'm not really sure what their purpose is, where should I put goauth.a and how do I import it?
To fix this I ended up including the source for the package in the directory tree for my app, as mentioned in this thread on the google-appengine-go group http://groups.google.com/group/google-appengine-go/browse_thread/thread/1fe745debc678afb
Here is the important part of the thread:
You may include as many packages as necessary. Packages are imported
by path relative to the base directory (the one that has your app.yaml
file), so if you have the following:
helloworld/app.yaml
helloworld/hello/hello.go // package hello
helloworld/world/world.go // package world
you can import "world" in hello and import "hello" in world.
If you are including a third-party library, it might look something like this:
helloworld/app.yaml
helloworld/hello/hello.go // package hello
helloworld/world/world.go // package world
helloworld/goprotobuf.googlecode.com/proto/*.go // package proto
Then you can, as normal, import "goprotobuf.googlecode.com/proto".
My team is developing a new DotNetNuke web application and would like to know what is recommended to setup a development environment with source control and automated builds? We would like to keep the DNN source code separate from our custom modules and extensions source code.
The DotNetNuke Compiled Module template for Visual Studio wants us to store the source code in the DesktopModules directory of the DNN source code and output to the DNN source code bin directory. Is this the recommended structure? I would rather keep the files in different locations, but then it becomes more difficult to run and debug locally as it would require an install of the module for each change. Also, how should an automated build deploy any changes?
How have others set this up? Is there a recommended best practice?
For my source control, I develop modules in their own project. This contains the module code, test code, data provider code (if applicable) and anything else. This is checked into source control like any other project. Note that the module project contains no links to a specific DNN website, and DNN references are made in the project to a common "bin" directory that references your target build. For example, in my projects folder, I have \bin460 , \bin480, \bin510, \bin520 etc. Each of these folders holds a set of binaries for a specific DNN version. That way you can build against a particular version but test against any version you like.
The problem with source-controlling a module in place in a dnn install is
- sometimes not all of the module code is easily isolated under a single parent directory
- doesn't lend well to a PA module approach
- not easy to shift the project to a different DNN Version for development or testing
- easy to inadvertently source control parts of the DNN solution, particularly with integrated VS source control solutions.
This approach compiles quickly because you're not trying to compile the entire project. For test deployment I have a build script that copies the various parts of the module into a target website. This can be done via the compile (link the build script) or just run after you've had a successful compile in a cmd window. My build script has a 'target' environment switch, so that I can say 'dnn520' to deploy the build to my test dnn520 install. Note that you need to manually create the module configuration first before this will work, but this is a one-time effort, and you can use the export feature to create your .dnn module manifest.
To build your module package, invest the time in a comprehensive script which will take the various parts from your source directory, and zip them into an install package. Keep all of the parts in your source control folder, and copy them into a temp directory, then run a command-line zip utility (I use an ancient version of pkzip) to pack it into an installable file.
The benefits of this approach is :
- separation of module code from installed code
- simple way of keeping only the module code in source control (don't have to exclude all the website code)
- ability to quickly test out modules in different dnn versions
- packaging script allows you to quickly and easily build a new version of a module for install testing/deployment
The drawbacks are
- can't use the magic green 'go' button in VS (have to manually attach debugger)
- more setup time than developing in-place
We typically stick to keeping the module code in a folder under DesktopModules and building to the website's bin directory.
In source control, we just map the individual modules, rather than the entire website. Depending on what we're working on, a module may be an entire project in source control, or we may have multiple related modules in the same project, living next to each other.
Automatically deploying changes is somewhat difficult in DNN. It's highly recommended to have a build script that packages your module into an installable form. You can then copy installable packages into the website's Install/Module folder, and get the URL /Install/Install.aspx?mode=InstallResources, which will install any packages in that folder.
In response to bduke's answer. You should, and don't want to build projects in the DesktopModules folder.
That's where all of the source code for the site out of the box goes.
That's where you modules will be "installed" and thus if someone "updates" or re-installs one, then it will be overwritten
It can make upgrading your Application far more difficult. Many developers don't understand that the idea of not touching the original source code files to modify their behavior. BECAUSE it will just be overwritten when you perform an upgrade.
If you want to build modules, create a solution folder called Modules and place your seperate project modules there.
If you want to debug them, make the target debug output point to the web\bin folder.
If you want to install/deploy them. Build it in release mode and install them through the Module/Extension filter.