I'm building an app in Meteor, and am a big fan the auto-rebuild action, that listens to any file change, rebuilds the app and refreshes my browser. However, I recently started to use flycheck with eslint and flycheck creates a temporary files called flycheck_my-module.js in the current directory whenever I make a change in a file (as opposed to only on save). Meteor sees these files being created and rebuilds and reloads. This causes a lot of action and is heavy for my browser and ruining my workflow.
I can customize the prefix for for these files f.x. to .#flycheck_ and that will make Meteor ignore them, however that will break the eslint checker.
So my question is. Is there any way to tell meteor to prevent all files starting with flycheck_ from triggering a rebuild, something like meteor run --ignore "flycheck_*.js".
Meteor handles the whole build process, so introducing something like flycheck isn't really ideal (same goes for transpilers, etc).
One possibility is to save those files inside the test folder, which is ignored by meteor. If the file is required to be in the same folder, you could quickly edit the source of flycheck to look in 'test/' + currentDir & recreate the same folder structure within the test folder. Not really ideal, but that's about your only option if you want to keep using flycheck + emacs.
Related
We have a CodePipeline set up which uses CodeDeploy to deploy the latest updates from our repository on GitHub to an EC2 instance. This works fine, except for one issue: everything we have in our .gitignore file is deleted from the server whenever a deployment is performed.
For instance, this is a WordPress site, so we have wp-config.php and wp-content/uploads excluded from the repository. When a deployment runs, it deletes these files rendering the site unusable.
Our desired behavior is for CodeDeploy to overwrite existing files, but also ignore any files/directories not included in the repository so they can remain untouched. By default there seems to be a step that "clears out" the deployment destination before adding the new files, but we need to skip that.
Is there any setting, either in the console or appspec.yml, which will allow us to make deployments without having anything deleted? It seems like this would be a very common use case...if we can't make deployments like this then I'll have to just do all our updates via SFTP, which is pretty lame.
We have a WordPress implementation, and assume CodeDeploy will remove all files and replace them with the deployment package. This is its standard behavior, and I am pretty certain you cannot change that. It will want to sync the local file system with the deployment package you have provided.
For this reason, consider moving the upload directory outside of the document root to account for this. Check out https://premium.wpmudev.org/blog/change-default-wordpress-uploads-folder/
Regarding files, we moved the upload folder to /var/files, and mounted that as a EFS volume. This provides you with better durability, and makes the file system independent of any given instance.
Also you should check in all files like wp-config.php on to the repo, for the same reasons - if you do not include it, then it will not be deployed.
With this approach we can easily replace instances via autoscalling. You may only have one instance at this time, but at some point you will want to scale.
But to answer the question directly:
Yes CodeDeploy can be configured so that files are retained the way you require.
You would implement a lifecycle hook script, where beforeInstall the reserved files are moved to /tmp, then the afterinstall hook would move them back. extra overhead for a deploy, which is why I suggest the above approach.
See https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-example.html
I have converted a Win32 Application to UWP using MakeAppX and it doesn't seem to run. When I click the icon in the start menu literally nothing happens except a busy icon briefly appears on the cursor.
I completed the same process with Notepad++ and all it's DLLs and that worked fine (using the exact same manifest file, just changing the exe)
My questions are:
Where does the UWP save files that it creates/temporary files etc? If I run an executable and it generates files next to it, where would that be when you run a UWP?
Can I set that location in the AppxManifest?
Is there anyway to see if it has run correctly or not?
Edit:
Could this be a file permissions issue? My application needs to write to 'C:\MyFolder' & creates a folder with a load of files next to the executable upon startup and that doesn't happen.
So looking into this a bit more I came across this blog which discusses preparing for conversion. I think the above file accesses probably contravene the following:
Your app writes to the install directory for your app. For example, your app writes to a log file that you put in the same directory as your exe. This isn't supported, so you'll need to find another location, like the local app data store.
This looks like a fairly halting issue, am I correct in that assumption?
If your app is writing to the install directory you will need to change that code to write to your local app data folder instead, as the preparation guide calls out.
Write operations to the install directory are not allowed in order to ensure the ability for the app deployment stack to perform seamless, differential updates and clean uninstalls of your app.
Btw, to debug through your app launch failures you can do the following in Visual Studio: Debug -> Other Debug Target -> Debug Installed App Package -> select your app from the list of installed apps.
I'm struggling getting knitr and jekyll to play nicely. I want to automatically regenerate my site, recompiling RMDs, if an RMD changes (handled by servr) or anything that would trigger a usual rebuild (as in jekyll serve --watch).
At the moment I'm use servr::jekyll() which automatically regenerates my site any time I modify an RMD - that's great.
However, if I modify just an ordinary MD file (that would usually trigger a rebuild in jekyll serve --watch), the site is not rebuilt.
If I try to pass --watch e.g.
servr::jekyll(command='jekyll serve --watch')
# or
servr::jekyll(command='jekyll build --watch')
then:
with jekyll serve --watch, it looks like the site gets regenerated every time I change an MD or RMD file, but the RMDs are not recompiled - jekyll will update MDs if they've changed and serve them, but not recompile an RMD.
with jekyll build --watch, the site isn't served (I guess this is not surprising, though even with serve=T it does not serve), and updating behaviour appears to be as with serve --watch - MDs are updated but RMDs are not recompiled.
if I do this in RStudio I can't return back to the prompt - I get the dialog that tries to get me to force quit and eventually the session crashes. I then have to find the jekyll process that is still running and kill it.
I guess this is because with --watch the call to jekyll doesn't return, so you never get back to R for servr to do its own watching? Even with daemon=TRUE, servr doesn't seem to re-knit the RMDs.
So my question is, how can I get (can I get?):
normal site regeneration as per jekyll serve --watch behaviour, and
automatic RMD re-compilation as per servr::jekyll() ?
I'm using jekyll 2.4.0 at the moment.
For now, if you run jekyll build --watch in a separate terminal, they work concurrently. Not an ideal solution, but good enough in the meantime.
I'm going to start using grunt-rev & grunt-usemin with grunt-watch for my web development needs (a RESTful Web App specifically).
I have a local development machine which will run grunt-watch to attach revision identifiers on my JS files. I git commit and git push my tree to a git repo, and then ask the production server to git pull the changes from the git repo to show them to the web visitors.
The problem is that I don't want my git repo to store different filenames (due to grunt-rev) on each commit. That would be bad, because then I wouldn't be able to do git diff between commits without having my screen get flooded with the contents of files that appear and disappear, and also it could (sometimes) take up a lot more storage than if it only stored the small diffs of the files.
The only solution I see is to add the build directory containing the versioned filenames in my .gitignore, so as to not store those files (with the constantly changing filenames) in git. But wouldn't that mean that I would have to run grunt-watch on my production server as well, in order to produce the build directory with the versioned filenames there as well? But that gets complicated: a new process has to run on the remote server, maybe with its small chances of error in processing the files. Not the solution I was hoping for.
Do you people have another solution? What would you suggest I did?
What I do to solve this, is to remove previous "build" files before committing and deploying a new file. There is no need to keep older files that have been generated, because you can always rebuild them with the source files (which are in git).
I've been cleaning up my directories and noticed that each Meteor.js project takes up at least 77MB (and typically, more like 150MB)! To figure out what was happening, I went ahead and created a new app:
meteor create myapp
At this point, the folder takes up about 7kb.
But after I do this
cd myapp
meteor
the folder size balloons up to 77MB.
After some digging around, I managed to pinpoint to size increase the .meteor/db folder. More specifically, running the app creates these local* files inside .meteor/db which are each >16Mbs. I opened these and they're mainly just a long string of 0000s with a few non-0000s here and there.
If I start doing more -- adding data, to Meteor.collections, etc -- the size balloons to 100+MB.
My questions
What are these files for and why are they so huge?
Is there any way to make my app smaller (zipping the folder cuts the size down to 1.8MB so a lot of the additional bloat looks like it could be stripped away somehow.
Running meteor in development mode (the default) creates an instance of mongodb for you under your .meteor directory. It's huge, I know. But don't worry - this is only for development so you don't need to setup your own mongodb instance on your localhost. You can clean it up at any time by running:
$ meteor reset
When you go to deploy your app, you will bundle your project which does not include any of these files.
To add to what David Weldon said.
If the size of the app locally is an issue, you could always use a Mongo database that is not stored locally, like a mongodb-as-a-service provider such as: MongoLab or MongoHQ
Also, for me using jasmine tests created a mirrors folder totaling 15Gb...