How can I use a local version of full calendar in my project? - fullcalendar

I'm trying to see if I can contribute a fix to a couple of issues we've been having with full calendar.
I've cloned the full calendar repo using git clone --recursive git://github.com/fullcalendar/fullcalendar.git and run yarn install.
I've gone into our project used npm link to link up the packages like so:
npm link \
~/dev/fullcalendar/packages/common \
~/dev/fullcalendar/packages/core \
~/dev/fullcalendar/packages/interaction \
~/dev/fullcalendar/packages-premium/premium-common \
~/dev/fullcalendar/packages-premium/resource-common \
~/dev/fullcalendar/packages-premium/resource-timeline \
~/dev/fullcalendar/packages-premium/scrollgrid \
~/dev/fullcalendar/packages-premium/timeline \
~/dev/fullcalendar/packages-contrib/vue
However, the packages don't seem to be playing nice with each other, seemingly they can't see eachother, so I get many, many errors when I try to run the project such as
ERROR in /Users/abarratt/dev/main/src/PODFather-Main/symfather/node_modules/#fullcalendar/common/main.d.ts(96,36):
96:36 Cannot find module './util/scrollbar-width' or its corresponding type declarations.
94 | export { CssDimValue, ScrollerLike, SectionConfig, ColProps, ChunkConfig, hasShrinkWidth, renderMicroColGroup, getScrollGridClassNames, getSectionClassNames, getSectionHasLiquidHeight, getAllowYScrolling, renderChunkContent, computeShrinkWidth, ChunkContentCallbackArgs, sanitizeShrinkWidth, ChunkConfigRowContent, ChunkConfigContent, isColPropsEqual, renderScrollShim, getStickyFooterScrollbar, getStickyHeaderDates, } from './scrollgrid/util';
95 | export { Scroller, ScrollerProps, OverflowValue } from './scrollgrid/Scroller';
> 96 | export { getScrollbarWidths } from './util/scrollbar-width';
| ^
97 | export { RefMap } from './util/RefMap';
98 | export { getIsRtlScrollbarOnLeft } from './util/scrollbar-side';
99 | export { NowTimer } from './NowTimer';
I'm assuming there's some yarn workspaces vs npm battle going on here but perhaps it's just something simple I need to tweak, or some step I've neglected.
Any help would be much appreciated :)

The answer it would seem, is yalc. By building using yarn run build as well as yarn run build-contrib followed finally with a manual yarn run ci inside the vue package (because something seems to break in the build-contrib script so it doesn't get fired properly), I was then able to publish and sym-link these correctly into my npm project properly, with all workspace linking resolved.
I've written the following bash script to do the job for me:
yalc-init-local-fullcalendar-link.sh
#!/bin/sh
if ! command -v yalc &> /dev/null; then
echo ""
echo "Hi,"
echo ""
echo "You must install yalc globally to link the local full calendar packages."
echo "You can do that by running"
echo "sudo npm install yalc -g"
echo ""
echo "Andy Barratt"
echo ""
exit
fi
START_DIR=`pwd`
if [[ -z "$FULLCALENDAR_DIR" ]]; then
FULLCALENDAR_DIR="$HOME/dev/fullcalendar"
fi
yalc_publish_packages_in_folder()
{
cd $#
for package in */ ; do
cd $package
echo "Publishing `pwd`"
yalc publish
cd ..
done
}
# Do some cleanup first
git checkout package.json
rm -rf .yalc
rm yalc.lock
rm -rf node_modules
npm ci
# Build full calendar
cd $FULLCALENDAR_DIR
yarn run build
yarn run contrib:build
# seems one of the other contributing packages has a bug in it,
# so we'll go ahead and run the vue one manually for now.
cd $FULLCALENDAR_DIR/packages-contrib/vue
yarn run ci
yalc_publish_packages_in_folder $FULLCALENDAR_DIR/packages
yalc_publish_packages_in_folder $FULLCALENDAR_DIR/packages-contrib
yalc_publish_packages_in_folder $FULLCALENDAR_DIR/packages-premium
cd $START_DIR
for package in node_modules/#fullcalendar/*/ ; do
package_name=#fullcalendar/`basename $package`
echo Linking $package_name
yalc link $package_name
done

Related

Wordpress on Fargate with ALB not working

So I've tried a couple of times with different Dockerfiles (which are succesfully pushed to ECR), but whenever I paste teh ALB DNS on the browser it shows this messagewordpress first page
Like theres no wordpress choosing language neither initial config, so I assume theres something wrong because If I complete those fields, then the error is this one wordpress error
Dockerfile i used:
FROM php:7.4-apache
# Install dependencies
RUN apt-get update && \
apt-get install -y libzip-dev && \
docker-php-ext-install zip && \
apt-get clean
# Download and install WordPress
RUN curl -O https://wordpress.org/latest.tar.gz && \
tar xzvf latest.tar.gz && \
rm latest.tar.gz && \
mv wordpress/* /var/www/html/
Nothing seems to word despite the instalation is being done
I've used this material to install it: https://www.internetkatta.com/host-wordpress-on-aws-ecs-using-fargate
Any help will be much appreciated
Wordpress on fargate. Couldn't get to work

zsh script is no longer working to update npm packages

I have used this script to update npm packages for a bunch of projects in a folder.
Today I tried (first time since apple has upgraded to zsh in their terminal) and it's not working.
for d in *; do if [ -d "$d" ]; then ( cd $d && pwd && npm update --save && git add . && git commit -m "package.json updates" && git push origin master ) fi done
This is the error I get:
zsh: parse error near `done'
Does anyone have any idea why its no longer working?
Thanks
As stated in my comment, there is a semicolon missing. So this should work:
for d in *; do if [ -d "$d" ]; then ( cd $d && pwd && npm update --save && git add . && git commit -m "package.json updates" && git push origin master ) fi; done

--allow-root doesn't work running wp-cli in docker container

When using WP CLI in docker, I need to execute it as root.
I need to add the flag --allow-root directly in .bashrc and I am trying to figure out why it doesn't work.
FROM webdevops/php-dev:7.3
# configure postfix to use mailhog
RUN postconf -e "relayhost = mail:1025"
# install wp cli
RUN curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && \
chmod +x wp-cli.phar && \
mv wp-cli.phar /usr/local/bin/wp && \
echo 'wp() {' >> ~/.bashrc && \
echo '/usr/local/bin/wp "$#" --allow-root' >> ~/.bashrc && \
echo '}' >> ~/.bashrc
WORKDIR /var/www/html/
my .bashrc
# ~/.bashrc: executed by bash(1) for non-login shells.
# Note: PS1 and umask are already set in /etc/profile. You should not
# need this unless you want different defaults for root.
# PS1='${debian_chroot:+($debian_chroot)}\h:\w\$ '
# umask 022
# You may uncomment the following lines if you want `ls' to be colorized:
# export LS_OPTIONS='--color=auto'
# eval "`dircolors`"
# alias ls='ls $LS_OPTIONS'
# alias ll='ls $LS_OPTIONS -l'
# alias l='ls $LS_OPTIONS -lA'
#
# Some more alias to avoid making mistakes:
# alias rm='rm -i'
# alias cp='cp -i'
# alias mv='mv -i'
wp() {
/usr/local/bin/wp "$#" --allow-root
}
when I try to execute any wp command I get this error:
Error: YIKES! It looks like you're running this as root. You probably meant to run this as the user that your WordPress installation exists under.
If you REALLY mean to run this as root, we won't stop you, but just bear in mind that any code on this site will then have full control of your server, making it quite DANGEROUS.
If you'd like to continue as root, please run this again, adding this flag: --allow-root
If you'd like to run it as the user that this site is under, you can run the following to become the respective user:
sudo -u USER -i -- wp <command>
It looks like that command line doesn't consider what I input into .bashrc
Guys, do you have any suggestion how to fix this problem?
You are struggling with the classic conundrum: What goes in bashrc and what in bash_profile and which one is loaded when?
The extreme short version is:
$HOME/.bash_profile: read at login shells. Should always source $HOME/.bashrc. Should only contain environmental variables that can be passed on to other functions.
$HOME/.bashrc: read only for interactive shells that are not login
(eg. opening a terminal in X). Should only contain aliases and functions
How does this help the OP?
The OP executes the following line:
$ sudo -u USER -i -- wp <command>
The flag -i of the sudo-command initiates a login-shell
-i, --login: Run the shell specified by the target user's password database entry as a login shell. This means that login-specific resource files such as .profile, .bash_profile or .login will be read by the shell. If a command is specified, it is passed to the shell for execution via the shell's -c option. If no command is specified, an interactive shell is executed.
So the OP initiates a login-shell which only reads the .bash_profile. The way to solve the problem is now to source the .bashrc file in there as is strongly recommended.
# .bash_profile
if [ -n "$BASH" ] && [ -r ~/.bashrc ]; then
. ~/.bashrc
fi
more info on dot-files:
http://mywiki.wooledge.org/DotFiles
man bash
What's the difference between .bashrc, .bash_profile, and .environment?
About .bash_profile, .bashrc, and where should alias be written in?
related posts:
Run nvm (bash function) via sudo
Can I run a command loaded from .bashrc with sudo?
I recently had the same problem. In my Dockerfile, I was running:
RUN wp core download && wp plugin install woocommerce --activate --allow-root
I looked at the error message, and thought that from the way it was worded, the --allow-root gets ignored the first time you use it. So I added it to the first wp command, and It worked.
RUN wp core download --allow-root && wp plugin install woocommerce --activate --allow-root
The problem is that ~/.bashrc is not being sourced. It will only be sourced in an interactive Bash shell.
You might get better results doing it via executables. Something like this:
# install wp cli
RUN curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && \
chmod +x wp-cli.phar && \
mv wp-cli.phar /usr/local/bin/wp-cli.phar && \
echo '#!/bin/sh' >> /usr/local/bin/wp && \
echo 'wp-cli.phar "$#" --allow-root' >> /usr/local/bin/wp && \
chmod +x /usr/local/bin/wp

Trial AppDynamics package fails to install

Getting below error during platform installation:
"Required libaio package is not found. ..."
However, above package is already installed:
rpm -q libaio
libaio-0.3.107-10.el6.x86_64
Here is output from the installation script:
./platform-setup-x64-linux-4.4.3.10393.sh
Unpacking JRE ...
Preparing JRE ...
Starting Installer ...
May 30, 2018 6:51:23 PM java.util.prefs.FileSystemPreferences$2 run
INFO: Created system preferences directory in java.home.
Verifying if the libaio package is installed. /opt/appdynamics/platform/installer/checkLibaio.sh
I got this too... I was running from command-line as a non-root user:
./platform-setup-x64-linux-4.4.3.10393.sh -q -varfile /appd/home/Install/response.varfile
I added the shell expand(-x) switch and log to the command(s) like so:
bash -x ./platform-setup-x64-linux-4.4.3.10393.sh -q -varfile /appd/home/Install/response.varfile > install.log 2>&1
If we tail the last bit of that log you get, this response in debug mode:
Verifying if the libaio package is installed. /opt/appdynamics/platform/installer/checkLibaio.sh
Required libaio package is not found. For instructions on installing
the missing package, refer to https://docs.appdynamics.com/display/PRO44/Enterprise+Console+Requirements
and the script checkLibaio.sh isn't left there... so you cannot figure it out easily. I also have a RedHat variant with the packages installed:
rpm -qa | grep libaio
libaio-0.3.109-13.el7.x86_64
Strangely enough I have one VM from the same image that will install the distribution just fine, and one that will not, so on the broken install (where I really want to install this). I ran another command from the expanded view of the install.log, which was a really long JVM command line. Anyways I got it to work and then made a looping script to retrieve the file (Because AppD for some reason removes the check script before you can look at it). The script is as follows:
#!/bin/sh
# Script used to check if the machine has libaio on it or not.
cat /dev/null > /opt/appdynamics/platform/installer/.libaio_status
chmod 777 /opt/appdynamics/platform/installer/.libaio_status
# Check if the dpkg or rpm command exists before running it.
command -v dpkg >/dev/null 2>&1
OUT=$?
if [ $OUT -eq 0 ];
then
if [ `dpkg -l | grep -i libaio* | wc -l` -gt 0 ];
then
echo SUCCESS >> /opt/appdynamics/platform/installer/.libaio_status
exit 0
fi
else
command -v rpm >/dev/null 2>&1
OUT=$?
if [ $OUT -eq 0 ];
then
if [ `rpm -qa | grep -i libaio* | wc -l` -gt 0 ];
then
echo SUCCESS >> /opt/appdynamics/platform/installer/.libaio_status
exit 0
fi
fi
fi
echo FAILURE >> /opt/appdynamics/platform/installer/.libaio_status
exit 1
I you run this script like me on the faulty platform what you will discover is that your version of Linux has both:
dpkg
and
rpm
installed. To work around this you should temporarily make a name change to one of these two package manager executables so it cannot be found (by your shell environment).
Most common here will be that you are running a RedHat variant where someone chose to install dpkg (For who knows what reason). If so desired remove that package and the install should be successful.

Meteor Up Docker and Graphicsmagick

I'm looking for how to install Graphicsmagick at Meteor Up Docker.
I found this solution (Access binaries inside docker) but I couldn't make work, where do I put those lines at start.sh?
meteorDockerId=docker ps | grep meteorhacks/meteord:base | awk '{print $1}'
docker exec $meteorDockerId apt-get install graphicsmagick -y
That's my start.sh:
#!/bin/bash
APPNAME=instagatas
APP_PATH=/opt/$APPNAME
BUNDLE_PATH=$APP_PATH/current
ENV_FILE=$APP_PATH/config/env.list
PORT=80
USE_LOCAL_MONGO=0
# remove previous version of the app, if exists
docker rm -f $APPNAME
# remove frontend container if exists
docker rm -f $APPNAME-frontend
set -e
docker pull meteorhacks/meteord:base
if [ "$USE_LOCAL_MONGO" == "1" ]; then
docker run \
-d \
--restart=always \
--publish=$PORT:80 \
--volume=$BUNDLE_PATH:/bundle \
--env-file=$ENV_FILE \
--link=mongodb:mongodb \
--hostname="$HOSTNAME-$APPNAME" \
--env=MONGO_URL=mongodb://mongodb:27017/$APPNAME \
--name=$APPNAME \
meteorhacks/meteord:base
else
docker run \
-d \
--restart=always \
--publish=$PORT:80 \
--volume=$BUNDLE_PATH:/bundle \
--hostname="$HOSTNAME-$APPNAME" \
--env-file=$ENV_FILE \
--name=$APPNAME \
meteorhacks/meteord:base
fi
docker pull meteorhacks/mup-frontend-server:latest
docker run \
-d \
--restart=always \
--volume=/opt/$APPNAME/config/bundle.crt:/bundle.crt \
--volume=/opt/$APPNAME/config/private.key:/private.key \
--link=$APPNAME:backend \
--publish=443:443 \
--name=$APPNAME-frontend \
meteorhacks/mup-frontend-server /start.sh
Re-installing the graphicsmagick package every time you re-start the containers seems like a hack I wouldn't want to do.
If you're modifying the start script already, might as well use a Dockerfile:
FROM meteorhacks/meteord:base
RUN apt-get install graphicsmagick -y
Then modify start.sh template to build a new docker image with graphicsmagick, tag it and use that image instead:
see: https://gist.github.com/so0k/7d4be21c5e2d9abd3743/revisions
EDIT: Where to put Dockerfile?
start.sh template is copied to /opt/<appName>/config/, currently the Dockerfile would need to be in that same directory (/opt/<appName>/config/Dockerfile)
see Linux init Task
Alternatively, you can specify specific Dockerfile with the -f flag for the docker build
Or your third option is to pipe Dockerfile to docker build using a here document
I've updated the start.sh gist, we no longer pull the meteord:base image and build it instead:
docker build -t meteorhacks/meteord:app - << EOF
FROM meteorhacks/meteord:base
RUN apt-get install graphicsmagick -y
EOF
The docker build will run every time, but as long as the requirements aren't changing, docker will use the docker images it cached.
The development Version of Meteor Up at Kadirahq allows specification of a custom Docker Image in the config file (mup.js).
MeteorD-Images with Graphicsmagick installed are available on Docker Hub.
This got me a working deployment (Meteor 1.3.2.4, Meter Up 309cefb, Node v5.4.1):
mup.js:
module.exports = {
…
meteor: {
dockerImage: 'ianmartorell/meteord-graphicsmagick',
…
},
};
I couldn't get the docker image that #bskp mentioned to work, so I figured out how to write one that uses abernix/meteord:base and then has graphicsmagick installed. Very simple, but it seems to be working for me on Meteor 1.4.1.1
I just did this in my mup.js file
docker: {
image: "joshjoe/meteor-graphicsmagick",
},
This was a huge pain to get working, so I'd be happy to help anyone who is struggling with this.
https://github.com/c316/meteor-graphicsmagick
If the if statement successes, you should be able to see a running container corresponding to the image you are grepping. In my opinion you can add the two lines after the fi to obtain the environment variable.
Build an image for get things right, but you can do temporary:
docker exec -it MeteorAppName apt-get install imagemagick -y
docker restart MeteorAppName
Check imagemagick: docker exec -it MeteorAppName convert -version
Why don't you add the following package meteor add cfs:graphicsmagick
https://atmospherejs.com/cfs/graphicsmagick
It tries to make sure Graphicsmagick is available. It worked for my use case i think it will work with docker too.

Resources