I have several Chrome Apps that share various assets (CSS, JavaScript, and the like), but it seems that all of the constituent files are required to be in the app folder. I don't want to put these files on a server, because I want the app to be entirely self-contained. I tried OS X aliases, but the Chrome system didn't recognize them in <script> elements.
Obviously, I don't want to maintain multiple copies of these files, as some of them change often during development.
Any ideas short of writing a preprocessor that's run every time a file changes? It would use a file called something like files.json that lists the assets not already in the folder or one of its subfolders.
We currently have experimental support for "shared modules", where one extension or app can depend on a set of others. The dependencies just provide files which can be loaded in the apps/extensions that depend upon them ; they cannot have any permissions or features (like a background page) of their own. At install time for an app/extension that depends on shared modules, we will automatically download and install any missing dependencies from the chrome webstore, as well as remove them later if you uninstall all apps/extensions that depend on them.
Right now the feature is only available in the dev channel of chrome, but we intend to fully support it when we've had a chance to get developer feedback. If you want to try it out, grab a copy of the chrome dev channel (or canary).
In the manifest.json for an extension that is just a bundle of files you want to share:
{
...
"export": {
"resources": [ "foo.js", "bar.js" ]
},
...
}
In the manifest.json for an extension/app that wants to depend on the above:
{
...
"import": [{"id": "<id of dependency goes here>"}],
...
}
See the test data files in this codereview for more examples:
https://codereview.chromium.org/13971005
(Sorry we don't have good documentation for this yet ; we will eventually)
Give it a try and send some feedback to extensions-dev#chromium.org or apps-dev#chromium.org.
Normally such are done via package manager. You can use bower to add some local git dependency. Or if you simply want to copy files to your folder every time the target files have changed you can use Grunt task runner with Watch task.
When I said "writing a preprocessor" I overstated what would need to be done. jusio's solution I guess works, but I did something even simpler, with this script run from inside BBEdit:
#! /bin/sh
cd /Users/marc/Documents/Dropbox/dev/chrome
rsync -vrt lib NoteTree
open '/Applications/Chrome Apps.localized/Default nnlinebecgjceggljgcnfploamgnjjhl.app'
This copies the changed files and then invokes the Chrome App. If it's already running, which it usually is during development, I just right-click and choose Reload App. It's a very quick edit-and-test cycle.
(Explanation: /Users/marc/Documents/Dropbox/dev/chrome is the parent folder for my development, subfolder lib contains the common files, and NoteTree is the app I'm currently working on.)
Related
I had my react project working correctly in localhost. Then, I decided to deploy it to github pages and it worked perfectly on the server too. Now, I'm trying to work on it again on localhost but it is not showing correctly. For some reason, photos are not loading and some css is not working correctly and after compile it in PowerShell says this:
Compiled successfully!
You can now view myportfolio in the browser.
Local: http://localhost:3000/myportfolio
On Your Network: http://192.168.56.1:3000/myportfolio
Note that the development build is not optimized.
To create a production build, use npm run build.
So if I go to my GitHub pages it is loading correctly but not in localhost (running npm start).
Any suggestion? Thank you in advance and let me know if you need more clarification
I did clone your repositories and found these problems:
You have been directly imported many third-party js given their relative path in the index.html. That doesn't work. You should append %PUBLIC_URL% before them. For e.g.
<script src="%PUBLIC_URL%/js/jquery.flexslider.js"></script> and similary for other script files.
But even this is not the best that you can do. You must not try to use jquery or third party js in a React App. Also, make it a part to install the related JS though npm and make them a part of the package.
You'll have to use <img src={require('/public/images/background.png')}... (Btw, the image name on your gh-pages is different. It's logo.png there)if you want the webpack to compile and make it a part of your project. Also, the path must reside within src and not public folder.
Other errors are are related to keys. Whenever you're mapping and iterating through a list in react you must specify a unique key.
I have one code base for both Web and NodeWebkit (NW) application.
I use the following stack:
- React
- Hapi
- Sequelize
- Windows environment
Web version of the application uses MySQL, while NW uses Sqlite. It all works fine. I have config file that compiles application for what I need (web or NW).
The problem that I face now is how to deploy the NW application. Idea is to provide NW applicaiton to a client, where he will open it clicking the icon.
Since I use the Node for the NW version, and the application uses many modules which are stored in node_modules, I face a challenge how to pack it all up.
My idea is to make an Windows installer. User will click it and the installer will extract all files to the destination. And also make an icon on the user desktop to run it.
Problem is with the Windows file name limitation. Inside the node_modules, there are many subdirectories that simply violate the Windows limitation. I cant even copy the node_modules folder. I cant even delete it. Well sure I can copy it If I zip it... or remove manually long folders.
I have not yet started working on the installer, but I am thinking I will hit the wall with this approach.
Does anyone have an idea how to make this deployment?
How can I integrate NPM3 in NW?
My plan now is to make Windows installer. That windows installer will install normally application files. The node_modules will be zipped previously and placed inside the installer. Installer will then simply unzip it to the destionation folder.
I will post my progress here.
Some update here.
Main issue here was the depth of the node_modules. I have many modules in node_modules, and after some thinking I figured out there is a simple rule there. Some modules are server side modules, while other ones are used by react.
And since Webpack already creates a huge files in which all of the modules are already included, I simply do not need them at all.
So I have removed all front end side modules(babel modules, react-*), and left only server side (Hapi, sequelize...). Miracle happened, application run and was much faster at the startup.
I am going to use Inno setup to make a manifest file, and it should be good to go.
I am still not out of the danger zone, as developer might need a server side module, which has huge depth. But I will think about that if it happens.
More to follow...
actually in nodejs you can do the following:
1-Create another folder inside your project folder for example "server_modules"
2-In the created folder create another package.json file and install any modules needed for server out there
3-All these modules will be accessible as normal node_modules using require('module_name') and you can delete "server_modules" folder when you package your desktop version if you don't need it
Note: this approach used by some developers to achive micro services in nodejs but it is useful in your case
I'm working on a Windows Store App (JavaScript/HTML/CSS) that will be deployed directly to devices in our enterprise.
I want to keep the datasources (urls to Restful web APIs) as part of the configuration rather than built into the app itself so that I can set them during deployment (e.g. to set test urls and prod urls).
More generally I want to store text variables in config that is external to the app and can be pulled in by the app somehow.
I thought I could set some environment variables or something but Windows Store Apps can't read them it seems.
Any ideas?
You could certainly make an HTTP request from the app on startup to retrieve a configuration file, but that of course assumes connectivity which may or may not work in your scenario. For a Store-acquired app, this is really the only choice.
In your scenario, however, you'll be doing side-loading through a Powershell, correct? (This is implied in installing directly to devices.) In that case, the Powershell script is running in full trust and will have access to the file system during the process. This means that the script can easily deploy a configuration file into the app's local appdata folder, which the app then picks up when it runs. The app package should also contain a default configuration file that it copies into that appdata folder if such a file doesn't exist on startup.
The documentation for the add-appxpackage script that does the install is here: https://technet.microsoft.com/en-us/library/hh856048.aspx.
Another option you might be able to use is to build different versions of your packages for test and production deployment. It is possible to configure the build process in Visual Studio to selectively bring in different versions of a file depending on your build target (e.g. Debug or Release). I have a blog that describes this technique on http://www.kraigbrockschmidt.com/2014/02/25/differentiate-debug-release-builds-javascript/. This would allow you to package different versions of a configuration file into the package, which you'd then read from the package install location at runtime or copy to appdata if you wanted to make changes at runtime.
I mention this method for building different packages because it's something that doesn't need you to do anything other than change the build target. It accomplishes what you would do with #ifdef precompiler directives in other languages, which aren't available for JavaScript.
I'm investigating the complexity involved in maintaining a cross-platform (web, ios, android) phonegap codebase that allows for platform specific code (and assets/tests) as simply as possible.
The current best approach I'm taking is to use grunt to build the code of a typical web app, and then use the grunt-phonegap module to generate the respective phonegap projects.
I'm confident this will work, however for my phonegap projects, I know I'm going to need to make use of some specially written plugins to make use of some device capabilities (these aren't typical cordova plugins)
I'm wondering if anyone has figured out an approach for maintaining a codebase that can adapt to different platforms and requirements. Javascript has no #IF_DEF functionality, but would it be possible to implement something like that using grunt?
I recently had the same question myself. I couldn't really find much online regarding this so I decided to deep dive into Grunt, Node, and Git.
Grunt and Node
In the root folder of my Cordova projects (alongside the www, platforms, merges, and plugins folders) I have a grunt project. I store modular JavaScript files and CSS files that may or may not be platform dependent inside a src folder inside the root of the Cordova project. This grunt project builds the JavaScript and CSS stored in the src folder and places the resulting files into the www or merges folder as appropriate.
I even wrote a grunt task that will make a production build of the app by optimizing and minifying css, javascript, and html templates, then rebuilds the Cordova platform projects to include these production files.
Because there is no #IF_DEF in JavaScript, I have to use Grunt (mentioned above) to build out the JavaScript for each platform. I modularize almost all of the JavaScript functions by platform. If there are no platform differences for that function (no native hooks), I only need one file. If there are differences, I need to create a separate file for each platform for that function. For example, my Cordova onDeviceReady and onResume function usually differ from platform to platform. I create files called
CordovaEvents-ios.js and CordovaEvents-android.js
Inside the package.json file, I describe the "features" I want in my app. CordovaEvents is an example of a feature.
I also support "arguments". I use the same approach above in the file names of the modular files. An argument could look like this
CordovaEvents-ios--production.js and CordovaEvents-android--production.js
In this case the code needed in a production app will differ from non production code. I can simply pass this argument (or list of arguments) during the build process, and the correct files will be picked up and built. I think this most closely addresses your question if there is an approach to maintaining a codebase that can adapt to different platforms and requirements. The requirements are the feature names and arguments. The argument can be anything you want, maybe using one plugin or another plugin.
I also describe the platforms I want to support ("iOS", "Android", and "Desktop"). Grunt processes each platform in a MultiTask, and then looks at the features I want to support. It will try to find a file called feature-platform.js. If it cannot find this file, it will just try to look for feature.js. After I concatenate all the functions together needed for the platform, it will copy the file over to the merges folder for iOS or Android. Typically all the files kept in the WWW folder in the root project will work on a desktop because there are no native Cordova hooks... this allows me to debug in Chrome. All the files that contain native hooks are stored in the merges folder. Once the Cordova project is built for the respective platform, the code can be tested in a device simulator.
If you are new to Grunt I would strongly suggest taking a look a their getting started guide.
http://gruntjs.com/getting-started
Git
I also employed Git to version my code. I used SourceTree to create the Git repository in the root folder of my Cordova project, and have a remote repository on my Mac Mini server that I can push my commits too. This allows us to have a backup copy of the code, and makes it so my team can also work on the code out-of-band.
I Git ignore the following folders:
node_modules
plugins
platforms
plugins
All the other files and folders contained in the root directory of my Cordova project are versioned. I used the following link as a reference to help define my Git strategy for Cordova:
https://leanpub.com/developingwithcordovacli/read#version-control
It didn't take me overnight to figure all this stuff out, in fact it took a little bit more than two months. I hope my answer can server as a guide to you and others to address your concerns you mentioned in your opening post.
I am using gruntjs, javascript, jade, bower, and phonegap to build hybrid web applications and phonegap mobile applications. After some investigation, I settled on to use jade template language for creating my html and javascript files. This is my setup.
//begin grunt module
module.exports = function(grunt) {
var $jadeConfigObject = {
compileDevelopment: {
options: {
pretty: true,
data: {
debug: true,
**phonegap : '<%= isPhonegapBuild %>'**
}
},
files: [{
expand: true,
cwd : "src",
src: "**/*.jade",
ext: ".html",
dest:"dist/development/www/"
}]
}
};
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'),
clean: [$dist_folder,"www"],
jade: $jadeConfigObject
// other gruntjs tasks
})
grunt.registerTask('setPhonegap', 'Set Phonegap related values.', function(n) {
**grunt.config.set('isPhonegapBuild', true);**
});
grunt.registerTask('buildPhonegap', ['setPhonegap','buildDevelopment'
,'copy:phonegap_www']);
}
Now explanation
Use gruntjs setPhonegap task to distinguish between phonegap build and normal web application build.
Task setPhonegap set isPhonegapBuild config property, this property, in turn, is used by jade config object. Then I can use "if phonegap" statements in jade files.
I have following line in my jade layout file
include ../includes/mainJavascript.jade
mainJavascript.jade
if phonegap
script(type='text/javascript',src='#{mainFolder}/cordova.js')
script(type='text/javascript',src='#{mainFolder}/cordova_plugins.js')
script(type='text/javascript',src='#{mainFolder}/plugins/org.apache.cordova.device/www/device.js')
script(type='text/javascript',src='#{javascriptServicesFolder}/pushTokenService.js')
script(type='text/javascript',src='#{javascriptFolder}/plugins/com.phonegap.plugins.PushPlugin/www/PushNotification.js')
script(type='text/javascript',src='#{javascriptFolder}/phonegap/pushNotificationHelper.js')
This way I have following features
My web application does not contain any phonegap related scripts or html
I can use jade layouts (Master Page) to simplify my files very easily.
Adding new javascript to every page or changing every html for every page in application very easy.
Note that phonegap wants www folder for its build scripts, therefore I create following directory structure.
src -- every code file here, jade, javascript
www -- only created for phonegap build
dist/development/www -- normal development www build
dist/production/www -- production www build
I ignore www/* and dist/* in my source control. I only work with src jade and javascript files. Add this setup to bower, I believe it is a good option.
I am in the process of converting an existing Rails 3.1 app I made for a client into a Backbone.js app with the Rails app only as a backend server extension. This is only a personal project of mine, to learn more about Backbone.js.
While setting up Backbone.js (using Backbone-on-Rails), I noticed I have some dependencies (like backbone-forms) that come from external sources and are frequently updated.
I've grown accustomed to using Bundler to manage my Ruby gems, but I haven't found anything similar for JavaScript files. I'm wondering if there is any way to do the same for Javascript (and possibly css) files.
Basically I can see three possibilities to solve this issue:
Simply write down all the sources for each JS file and check these sources from time to time to see what has changed.
Use some kind of existing "Bundler for Javascript" type of tool, I've been looking for something like this but have yet to find anything (good).
Since most of these JS files will be coming from Git anyway, use Git to get the files directly and use checkout to get the latest version from time to time.
I prefer the last option, but was hoping on some more input from other people who have gone this route or preferred some other way to tackle this issue (or is this even an issue?).
I figure the Git way seems easy, but I am not quite sure yet how I could make this work nicely with Rails 3.1 and Sprockets. I guess I'd try to checkout a single file using Git and have it be cloned in a directory that is accessible to Sprockets, but I haven't tried this yet.
Any thoughts?
You don't mention it in your alternatives, but ideally you should use something like Maven to manage your dependencies. Unfortunately, there are no public repositories for javascript files. This discussion lists some other options which might be of help to you: JQuery Availability on Maven Repositories
For now I've settled on using the Git solution combined with some guard-shell magic.
The steps I follow:
Create a dependencies directory somewhere on your local drive
Clone the repositories with javascript (or css) files you want to use in the app
Set up a custom guard-shell command to do the following:
group 'dependencies' do
guard 'shell' do
dependencies = '~/path/to/dependencies/'
watch(%r{backbone-forms/src/(backbone\-forms\.js)}) {|m| `cp #{dependencies + m[0]} vendor/assets/javascripts/#{m[1]}` }
end
end
Place the Guardfile at the root of the app directory
It takes some time to set things up, but after that, when you have the Guard running, and you pull changes into your dependencies, the required files are automatically copied to your application directory, which are then part of your repository.
It seems to work great, you need to do some work for each new file you want to include in the asset pipeline, but all that is required is cloning the repository in your dependencies directory and adding a single line to your Guardfile, for example for the backbone-form css:
watch(%r{backbone-forms/src/(backbone\-forms\.css)}) {|m| `cp #{dependencies + m[0]} vendor/assets/stylesheets/#{m[1]}` }
Also, the reason I added this Guard to a group is because I keep my dependencies outside the main application directory, which means guard normally doesn't check my dependencies directory. To make this work, I start up my main Guard processes using bundle exec guard -g main and use bundle exec guard -w ~/path/to/dependencies -g dependencies in a new terminal window/tab to specify the -w(atchdir).