Background:
We have an Angular 2 application that we would like to start using AOT compilation for. Simple enough... except for one of my dependencies...
We use autobahn.js for communicating to our servers over a web socket connection. The issue is with loading this dependency in rollup.
The authors of autobahn.js have decided that for their browser version of the library they will host it in bower (fair enough) instead of npm.
We have a library that wraps autobahn.js with some nice utilities and handles other things for us. This is great because it is a universal solution. This library can be used in both the browser and in our node.js servers. (yay)
However the node version of autobahn uses fs, url, and other node specific features. (boo)
The bower version of their library uses the correct equivalents for the browser which is good.
In the wrapper we have an import * as autobahn from 'autobahn'; (we use typescript) This works great in node, and also worked ok with some configuration in SystemJS.
Problem:
How does one tell rollup (or the rollup-plugin-commonjs) to point to the bower_components/autobahnjs/autobahn.js file instead of the node_modules/autobahn/index.js file as it does by default.
Current configuration:
import rollup from 'rollup';
import nodeResolve from 'rollup-plugin-node-resolve';
import commonjs from 'rollup-plugin-commonjs';
import json from 'rollup-plugin-json';
import uglify from 'rollup-plugin-uglify';
export default {
entry: 'dist/iss/index.js',
dest: 'dist/iss/bundle.js',
sourceMap: false,
format: 'iife',
moduleName: 'statusMonitor',
external: [
'autobahn',
'moment',
'moment-timezone'
],
context: 'window',
plugins: [
nodeResolve({jsnext: true, module: true, browser: true}),
commonjs({
include: 'node_modules/**'
}),
json(),
uglify()
]
}
Other Option:
Another option that would work for us is that autobahn also works as a global, and if we could patch rollup to use the global autobahn off window then that would work for our use case.
There's a rollup-plugin-bower-resolve plugin which is analogous to node-resolve – if you include that in your plugins array before node-resolve (or use the skip option in node-resolve) then it should be able to find autobahn.
It's now on npm
https://github.com/crossbario/autobahn-js-browser
The browser version is published to npm under the name autobahn-browser. Install with:
npm install autobahn-browser
Note: the NodeJS version of Autobahn continues to be published under the name autobahn.
Related
On Mac, when I run my app from WebStorm, exiftool-vendored works great. However, when I build my app (I use electron-builder) and install it on the same Mac, it never returns, even just trying to get the version:
exiftool.version().then(version => writeBreadcrumb('exif', version))
In other words, no error is raised, and the then is never executed when running an installed version of my app, though it works fine running my app from WebStorm (with cd build && electron .)
What am I doing wrong? Is there an example anywhere of how to use exiftool-vendored in an electron app?
You should take a look at what the docs say about making it work with Electron:
How do you make this work with electron?
Electron is notoriously brittle and buggy, and is not officially supported by this package. Although PhotoStructure uses this package within electron, there's a nontrivial amount of auxiliary support code specific to that project to make it work smoothly.
If you're still anxious to try, here are some things to keep in mind:
Note that this package will spawn exiftool external processes, which means the exiftool-vendored.pl and exiftool-vendored.exe packages should be included in your asarUnpack. SmartUnpack might work, but if it doesn't use a pattern like node_modules/{exiftool-vendored.*}/**/*.
If you're requiring exiftool-vendored from within a webview, you're gonna have a bad time. Many things won't work due to a lack of node compatibility within electron.
__dirname at runtime from within an asar package after webpacking will be invalid, so don't rely on that.
— https://github.com/photostructure/exiftool-vendored.js/wiki/FAQ#how-do-you-make-this-work-with-electron
Since I never found a way to get exiftool-vendored to work with electron on Mac, I accepted the above answer, as essentially a warning to steer clear of exiftool-vendored for electron on Mac.
This answer is included for completeness, for those of us who need exiftool in an electron app for both Mac and Windows:
I used node-exiftool with these settings added in package.json for electron-builder:
"build": {
...
"win": {
...
"extraResources": "exiftoolwin/**/*"
},
"mac": {
...
"extraResources": "exiftool/**/*"
}
}
In the root of my project, I added folders exiftoolwin and exiftool. In exiftoolwin, I put exiftool.exe which I obtained by following the Windows Stand-Alone Executable instructions here, and in my exiftool folder I put exiftool and lib which I obtained by extracting the full perl distribution on Mac, as described on the same page.
Then, in my .jsx (I'm using React):
import exiftool from 'node-exiftool';
const exiftoolFolderAndFile = process.platform === 'win32' ? 'exiftoolwin/exiftool.exe' : 'exiftool/exiftool';
const exiftoolPath = path.resolve(__dirname, '../..', exiftoolFolderAndFile);
const ep = new exiftool.ExiftoolProcess(exiftoolPath);
Then I just use ep as described here.
This is working for us:
add this dependency:
"exiftool-vendored": "^15.2.0",
Update package.json "build" section for mac ( not needed for windows as far as we can see )
"build": {
"mac": {
...
"asarUnpack": [
"node_modules/exiftool-vendored/**" ,
"node_modules/exiftool-vendored.pl/**"
]
}
}
The question may not be precise, but this is what I am trying to achieve:
The puppeteer-core NPM package requires a headless browser at runtime, and I found that I could use it with the latest Chromium in Nixpkgs. My current workflow:
I have overridden the node2nix-created default.nix with override.nix by adding Chromium to buildInputs:
{pkgs ? import <nixpkgs> {
inherit system;
}, system ? builtins.currentSystem}:
let
nodePackages = import ./default.nix {
inherit pkgs system;
};
in
nodePackages // {
shell = nodePackages.shell.override {
buildInputs = [ pkgs.chromium ];
};
}
Issue nix-shell override.nix -A shell.
export CHROMIUM_PATH=$(which chromium)
Setting up Chromium in the javascript files via process.env.CHROMIUM_PATH.
This works well, and the project can be shared easily with others by creating a tarball, but they would have to set up the environment manually as well, and I also don't like Chromium being included in the build dependencies. I could have just installed it globally with Nix, but the rest of the manual steps would still be there.
I read the manuals, and getting comfortable with the language, but haven't built a derivation or a package yet, therefore I'm sure I missing something obvious.
Some of the discussions I found on the topic:
https://nixos.org/nixos/nix-pills/automatic-runtime-dependencies.html
Runtime-only dependencies #1080
https://discourse.nixos.org/t/handling-dynamic-runtime-dependencies/323
After upgrade and dismissing Bower as recommended: Is there a way to include JQueryUI into an Ember project without using Bower? My project depends heavily of JQueryUI dialogs.
$ ember -v
ember-cli: 3.3.0
node: 8.11.3
os: linux x64
Do I have to reintroduce Bower into my project? Like in this old Using jquery in Ember-cli advice?
does this solve your use case?:
ember install ember-auto-import
npm install jquery-ui
and then wherever you need to use it:
import { stuff } from 'jquery-ui';
Including external js through npm package is always suggested. Above answer shows how to do it.
Sometime the developer won't maintain the package. In that case, you have to include it manually to get the latest js for your app.
If you want to include it manually (not depending on the npm package), here is the way to add external js in your application
1) Download the latest stable jquery-ui from their official site.
2) Extract it. Include jquery-ui.js file in your app/vendor/jquery-ui.js
(Where vendor is the home for external js)
3) Once added import the js in ember-cli-build.js file
app.import('vendor/jquery-ui.js');
4) Restart the ember app.
I was able to get it to work by adding "jquery-ui": "^1.13.2", to my package.json file.
Inside ember-cli-build.js I added the following
// jQuery UI
app.import({
development: 'node_modules/jquery-ui/dist/jquery-ui.js',
production: 'node_modules/jquery-ui/dist/jquery-ui.min.js',
});
// jQuery UI CSS
app.import({
development: 'node_modules/jquery-ui/dist/themes/smoothness/jquery-ui.css',
production: 'node_modules/jquery-ui/dist/themes/smoothness/jquery-ui.min.css',
});
I've been thinking about using React as the frontend for a Grails application, but I'm having a bit of trouble getting started.
So far, I've become accustomed to write a React app using Node/NPM with the help of Webpack, and that's been pretty easy because there is plenty of documentation for that setup.
However, I'm struggling to find anything concrete integrating React seamlessly with Grails.
Ideally, I would just do grails run-app and it should take care of everything. I do not want other team members to worry about starting up two different servers or something along those lines.
Please let me know if anyone has done this before.
Webpack can be configured to work quite well with Grails. The key is to have webpack generate its bundle whenever the app is started up, and to output the bundle in a directory where it can be served from the GSP. You do not want your source JavaScript (I.e, React/ES6 code) in the asset pipeline if your using Webpack, instead you want to keep those source files in another directory (such as src/webapp), and configure Webpack to bundle these files and output the result to the asset pipeline (assuming you're using AP at all).
Here's an example configuration for Webpack:
var path = require('path');
module.exports = {
entry: {
index: './src/webapp/index.js'
},
output: {
path: './grails-app/assets/javascripts',
publicPath: '/assets/',
filename: 'bundle.js'
},
Finally, to achieve the integrated webpack/Grails startup, you can use the Gradle node plugin and attach the webpack run script to the application startup in a custom task in your build.gradle (this is assuming that you have a npm script named "webpack" defined to run webpack)
assetCompile.dependsOn(['npmInstall', 'npm_run_webpack'])
Please note that if you want to run webpack in "watch" mode, you'll need to do that seperately from starting up the Grails app, so that that script can run continuously (there actually is support for this in the Gradle mode plugin but it's currently broken).
See this link for a more in-depth explanation of this approach, with a sample application: http://grailsblog.objectcomputing.com/posts/2016/05/28/using-react-with-grails.html
Also checkout the React profile for Grails 3: https://github.com/grails-profiles/react
It has not been released yet but should be in the next few days. It makes use of the same approach outlined here and in the linked post.
You could use npm's scripts feature to combine all steps necessary to start up the development environment into a single command, e.g.:
// package.json
{
...
"scripts": {
"start": "npm start-grails & npm start-react",
"start-grails": "grails run-app",
"start-react": "node server.js"
},
...
}
Now all it takes is a simple npm start to launch all relevant applications.
In my ember cli app I have moment in both directories, but my ember server only works with the bower path, in my borcfile:
app.import("bower_components/moment/min/moment.min.js");
app.import("node_modules/moment/min/moment.min.js");
the latter says that it can't find it.
In order to reference node modules you ll need to import them by their name, the simplest example is: import Ember from 'ember'.
For more info regarding modules and the resolver refer to this part of the documentation