I'm new to ember and after following a few guides, I've been playing around with ember apps. I'm using ember-cli to create an app, so I use
$ ember new 'app-name'
which creates the app as expected with the 'app' and 'dist' folder. But it also creates a lot of other files. I only discovered this while deleting the folder when the windows delete dialog box showed deleting more than 30000 files.
Is it that I'm doing something wrong that's causing unnecessary files to be created? Is there a way to avoid this?
You aren't doing anything wrong, a big portion of it is the dependencies and then the build process keeps a lot of temporary files around for reuse.
By the way, if you are developing in Windows, make sure you are running your command prompt as administrator, and that you've excluded the ember app from the virus scan, it really improves the build times.
It's not an issue with ember-cli itself, but how npm handles dependencies, since it has a hierarchical dependency system. You could try npm 3 (be warned, it's still beta - changelog), which tries to flatten out the dependencies better.
Another thing is checking if bower packages are adding any unneeded dependencies, like tests or raw source files (if they have pre built files). You could submit a PR to those projects by adding the ignore property in the bower.json file. See the spec here. Same with npm packages, which has a .npmignore file.
This is probably not what you wanted to hear, but in open source, we must all help each other. These are the bread crumbs of open source, and a great place to get started.
Related
Im looking for a reasonably simple toolset and workflow for incorporating Sass into my Django projects. Im predominantly backend focused and have just started investigating Sass, so bear with me.
My initial idea was to keep things simple by just using node-sass without trying to incorporate Gulp, django-pipeline or anything else initially.
My Django apps are usually structured such that I create a static/app/css folder in each app. One option I guess would be to now create an additional folder per app for scss files, ie: static/app/scss. The problem there would be that when running collectstatic in production, the scss files will be gathered as well. So should the scss files for each app be kept somewhere else? (I guess it doesn't really matter if the scss files are included when collectstatic runs?)
Next, outside of my Django project folders I would create a folder to install node-sass since I wouldn't want to install it globally and I don't want the node-modules folder inside my Django project or inside source control.
I guess the node-modules folder can be thought of like using a python virtualenv instead of installing packages globally?
Next, inside my Django project somewhere (not sure where?) I would have the package.json file containing a scripts section for every scss file I want compiled to css, eg:
"scripts": {
"compile:sass": "node-sass app1/static/app1/scss/style.scss app1/static/app1/css/style.css",
"compile:sass": "node-sass app2/static/app2/scss/style.scss app2/static/app2/css/style.css",
"compile:sass": "node-sass app3/static/app3/scss/style.scss app3/static/app3/css/style.css"
}
Lastly, I would just run compile:sass with the watch flag to constantly compile any files I work on and put them in the correct folders.
So my questions are, is the above setup a good approach (at least initially if im not ready to add yet another tool like Gulp etc to the mix)?
Also, how will I run compile:sass considering my package.json file will be in the Django project somewhere and the node-modules folder containing the node-sass installation will be somewhere else.
I help maintain node-sass, so I won't say not to use it. There is an alternate libsass-python that you might want to look at if you're working with Python though.
Check out the django-sass-processor package. It's simple to configure and use. I've used it a few times and have had good experiences with it. The package abstracts away Gulp, so you don't have to worry about it and streamlines the whole process.
Here's a tutorial on how to integrate django-sass-processor into a Django project.
with the release of angular2 I actually encountered typescript, npm, ... for the first time, and I really appreciate its power, so I barely grasp the surface.
In the "development mode" I can find my way, but in the end:
Question:
I want to generate an independent folder that includes all necessary dependencies: js, css, html-files and is portable without needing npm, transpilers,... anymore. (So basically I want to copy this generated folder to a server and people can access the index.html as usually)
Problem
Setup
npm (as a module manager and build tool) npm as a build tool, npm as a build tool II
typescript (tsc as transpiler)
angular2 (with separated files for html, css), SystemJS
Needed Guideline
An (abstract) guideline for what steps to take in order to achieve the prescribed goal, namely a folder that has (all) the features and is build from the typescript files, (probably .scss-files,...) in a separate and self-contained way.
Probably I am searching for the wrong keywords but I have only found some fractions of my answers so far and I would really appreciate a list (of tutorials, or so) that I can stepwise go through. (Currently I feel lost)
I would have a look at the systemjs builder, using a build process such as gulp, gulp-inject to configure the index.html, and consitute the build like this:
build typescript files
bundle js files using systemjs in the build folder
build scss files (there must be a plugin for gulp) in the build folder
copy all html files in the build folder
inject dependencies in index.html
This is a raw answer to your question, untested, and from the top of my head, but I hope it can lead you to a solution. I have a little something in this repository.
Is there an easy way to zip the dist folder as part of my ember build?
ember build --build=production
Are there some hooks that I can use?
This used to be something that could be handled in a simple addon using the postBuild hook. However, the point at which this hook is called was recently changed so that it fires before everything is copied into dist. It's understandable that some may need this behaviour but it screws anyone who was relying on the files being in dist already when postBuild is called. I opened an issue about it here but it doesn't appear to have much movement.
Meanwhile, I do as #anschoewe suggests and use a shell script which calls ember itself, then tends to my postBuild needs.
I use a prod_build.sh file and just run that.
$> ./prod_build.sh
the script just calls ember b --environment=production and zips up the final build contents zip -r <my_folder>
What is the best way to uninstall a package or a module in Sitecore?
I've seen suggestions to do it manually, but it is not very convenient way, especially when there were many templates, items, layouts, renderings and static files.
You can use Sitecore Rocks to create an "anti-package."
https://www.sitecore.net/nl-be/learn/blogs/technical-blogs/trevor-campbell/posts/2013/02/28-days-of-sitecore-rocks-package-management-part-1.aspx
I have never tested the Package History module that was mentioned, so I cannot comment as to whether that approach works.
Open the .zip file for the original package and look through the XML to figure out what files the package installed. Then back up your site and remove files and configuration nodes the package installed(assuming you are confident you understand what purpose the files and nodes have and what other components may rely on them). The Package History module may be taking this same approach, but you need to be certain that what you are deleting is not going to break anything.
Otherwise, I would recommend restoring to a backup made before you installed the package.
I have a package I want to install. I would like the files to end up in a different directory than the installation wizard choses for them.
For example, my Sitecore copy is running at C:\SiteCore\website
The module added files to C:\SiteCore\website\Console
I would like the files to ultimately live at C:\SiteCore\website\sitecore_modules\Console
I am using Sitecore 6.5 rev 111230, but we are planning to upgrade very soon. I would like for my installed packages to migrate seamlessly once we have upgraded. For reference, the package I want to install at the moment is the Sitecore Powershell Extensions. Although, I would prefer to apply a similar method to any future packages that I install.
Is there a secret switch in the package installation process to allow me to do this? Can I do it from the package installation wizard? Is there another way to install packages?
I'm assuming I can't just change the package path and expect everything to keep working. Do I have to update a configuration somewhere (a file or inside the Sitecore CMS GUI) to make the package recognize the new file locations?
The module creator defines where files exist. If you move them you run the risk of something not working. The best idea is to ask the creator on the Marketplace page of the module.
There is no turn-key way to change this.
I guess you cand take the code from MarketPlace and you can modify it.
I don't know how exactly is the licenses with MarketPlace modules, but I think people can modify others code.
Please check on code and also on items, maybe on some fields are values for folder path.
I discovered a way to accomplish this, but it can be quite involved or even impossible, depending on the complexity and size of the package.
First of all, I did take the question to the module creator and had a very helpful and informative conversation with the creator. So thanks for that suggestion - they may even move the install location in a future release, based on my request.
The workaround is to first install the package on a system as normal. Then you figure out everything that comes with the package. For files, this is easy if your Sitecore root is under source control. For items, this is really complicated. You can search for the installed items by owner, if you had the foresight to create & use a unique user for the package installation. Or you can check the untyped files in the package that are essentially xml based item manifests.
Once you have a detailed list, you make the desired modifications to the locations. Then you recreate the package yourself using the Sitecore package designer.
This works for simple packages - I did it to one small package that I hope to get up on the Sitecore marketplace as shared source soon. And by small, I mean it was 2 files and 3 items. The package that prompted me to ask this question would not cooperate with this workaround. The included .dll had some assumptions about the file structure hard-coded into it.
The workaround I took for the more complex package was really quite basic: I just created a new source-code external to the required path. That let me wrap everything up neatly without getting medieval on the package files.
Thanks for both your answers, a very fine +1 to you.