I use bower to manage the client-side dependencies in a Polymer project.
The problem I have is that some elements pull in a lot of stuff which is not needed in prod, and maybe not even while developing.
E.g. one component ships a demo .mp4 and .jpeg file increasing the size by almost 7 MB.
Is there a best practice to clean up the bower_component folder from unneeded stuff?
Related
We are building all the solutions to a shared bin directory. Having different projects reference different versions of the same dependency is not healthy for our build.
So, we consolidated the dependencies - great. But now the versions start to drift again. We do not want to consolidate them manually every now and then - we want to prevent the drift completely.
Why we do not want to use Paket? The main reason is that it seems we would lose the ability to migrate the NuGet package dependencies to the new PackageReference items in the projects. So, currently we have package.config files, but we plan to replace them with the respective PackageReferences. That means we will use internal NuGet support by msbuild, which seems to leave no place for Paket.
Now, I assume we are not unique in this world and others have the same problem as we are. How do you solve it?
EDIT 1
We have our internal NuGet repo, but we use it for dependencies which do not have organic representation in Nuget.org and for sharing our own internal packages.
One approach is to consume only from the internal NuGet repository. This has challenges, like:
Who uploads the dependencies there? Developers? But then how to make sure they do not upload different versions of the same dependency? Dedicated people? Then they become a bottleneck.
Small thing, but we need to block commits to the central NuGet.config
Uploading a dependency to the internal NuGet repo is not immediate. You cannot just download it from NuGet.org and upload to the internal one, because that would miss any transitive dependencies. So, a process should be built around it.
It is all possible, but I am reluctant to go down that route ... Must be a better way.
EDIT 2
While we do plan to migrate to PackageReference, it will take time. And unfortunately as long as we have Silverlight (another year, at least) a whole bunch of projects in the dedicated Silverlight solution (80+) will not be migrated to PackageReference, because by doing so it becomes impossible to debug the code with VS 2015.
Next, suppose we do migrate ALL the projects and then externalize all the PackageReference items to a single targets file imported by all the projects. This is feasible when using a shared bin directory as we plan to do. But when inspected in VS 2017 this setup communicates a wrongful picture that every single project depends on the entire set of NuGet dependencies.
I would rather avoid this.
Once you move to PackageReference, you can take advantage of MSBuild. For example, you can have a MSBuild file that contains all your dependency versions. It could be a file that you need to <Import ... /> in all your csproj files, or you could use Directory.Build.props. Finally, in each of your projects, change the version number in any <PackageReference to a MSBuild variable that uses the property you previously defined. Most of Microsoft's open source repositories use this technique, with minor variations about file names and whether it's imported automatically with Directory.Build.props, or an explicit <Import ... />.
While you can still use the Package Manager UI in Visual Studio to check for updates, you won't be able to update the package versions with it (at least, it won't preserve how and where the versions are defined). However, just make sure your MSBuild file that defines the versions is in your solution, so you can trivially open the file in Solution Explorer and then type the new version number in. Adding new package references is slightly more effort, but it's generally not done often, and it's still very easy with SDK-style projects, since Visual Studio lets you edit the csproj while the project is still loaded.
Since you didn't accept the other solution, maybe you could take a look at paket
It's a package manager for dotnet than (among other feature) holds solution wide dependency lock file. It is very customizable, and while it solves LOTS of problems, as any tool, creates some new ones. In my experience, the new ones are far less infuriating :)
I've created a new foundation project using the foundation new myproject --libsass method.
Its just a simple static index.html (for the purpose of this question).
I've deployed it to a live server now, and I am wondering about the best way to structure this. I have omitted the node_modules & scss directories, and i'm left with the following:
bower_components/
css/
js/
index.html
bowerrc
bower.json
Gruntfile.js
humans.txt
package.json
README.md
bower_components is needed in its current form, unless I shuffle some files around, which is what I intend to do, but I'm checking if there is a better way of doing this, and that I haven't missed some magic terminal command to deploy to production.
As msturdy suggested in the comments, grunt is the way to go here. There are a lot of plugins out there, see a list on the official page.
If you want to have grunt "compile" your project into one specific folder which you can then for example push to a deployment server, you should do several things in grunt:
compile your scss
minify your javascript, that is making the files smaller, see jscompress for a demo of what it is. All your js-files from /bower_components which you include in your project should be in a vendor.js which is loaded first, and then a second js-file should contain your custom js from /js
save everything into a deployment folder.
(optional) automatically deploy to a server.
Take a look at these grunt tutorials for setting up your gruntfile.js, you'll want to have two tasks, one for just quickly compiling your scss, one for the whole deployment process:
grunt is not weird and hard
official tutorial
sitepoint tutorial
They show you how to do certain things and definitely how to write the gruntfile. Plugins you might want to use apart from your current libsass plugin are uglify and any plugin that lets you deploy your code via git, ftp or anything else. You can download all these plugins via npm by adding them to your package.json and doing npm install, refer to their websites for exact usage instruction.
I am in process of setting up a whole series of NuGet packages for our framework. Beside the simple binary-packages (.dll's for modules of the framework) there are also packages that deliver source-code into the projects that are using them done with the \content directory in the NuGet package.
To develop this source-code I have a test-/sandbox project. I develop/debug/fix the code in this peoject and if its final for the next release, I copy it over to the package's content-folder where I replace things like $rootnamespace$ etc. This needs to be done for each and every version of the package.
Another way is to keep only the final source with the $rootnamespace$ tags in it and maintain that directly. But then testing/debugging would be done by re-adding the package to a test-project and debug it there, go pack to the package content, modify it, re-build and re-add and test it again.
So I see two ways to maintain the content-sourccode (none of them is really good):
Keep source-code in \content as small as possible and deploy as much as possible as binaries.
Generate the \content using some transformation engine (eg. T4) from the sandbox/dev-project. What engine would be best to use for this?
In short: I didn't find a good workflow yet to maintain the "content" source-code of NuGet packages. How are you guys doing this? Any ideas for that workflow?
Check the http://github.com/maartenba/MvcSiteMapProvider build. It is customized quite a bit but basically does a find/replace on several namespaces and replaces them with replacement tokens right before packaging.
I have two related apps I am developing in Scala. One is a server-side processing engine built using SBT and running headlessly doing some number crunching (on a cron job). The other is a web site written in Scala and running on the play framework.
I have code that I would like to be able to share between the two, but as each of them (SBT and Play) has their own ideas about directory structure and how to build things it's pretty unclear to me how I should do this. I'd hate to copy and paste the .scala files - but I'm also not keen on using sym links and having them both build from the same files.
If it were possible, I would accept getting the Play scripts to run SBT to build libraries as required. If it were the only way then I would also be OK with using SBT to build jars for Play and then copying them into place. But I'm often developing both simultaneously (they are parts of a bigger app) and it would all work much more smoothly if they updated together. Is this even possible, or if there's another simpler technique I'm missing?
Thanks, Alex
The only easy way is to build JARs with SBT and make Play use them.
On how to copy, you have 2 options:
You manually build and copy them over to the libs folder in Play (you can script that to make it less annoying)
You use a custom repository for your JARs (ala Nexus repository) and use Play dependencies.yml to point to that repo and update. With this you would also need to run play sync --deps often and to tweak the versions, so I'm not sure if it makes too much sense during dev (it makes more sense once the JARs are complete though)
i am looking to make our deployments here not suck and i need some help, if you can help me with these few things i owe you beer
right now whenever i make a change thats not to the jsps i need to clean-including-tomcat otherwise my change doesnt take. this is really annoying.
any clues as to what i can change to make it work?
my current build is really simple, just the regular old, javac, war, deploy
one thing that isnt done is that there is no build dir, the project itself contains a web-inf and the javac is done in place, then the war excludes all the .java resources and wars the project.
edit:
I am looking to fix this problem with least amount of effort - so while switching to maven and learning how to use it might solve this problem, but it will create another problem ;)
You've already identified some of the weaknesses, in your current build.
The easiest way that I can suggest to clean it up would be to start with the directory structure.
I highly recommend using the maven directory structure, I would go further to suggest using maven as a build tool instead of ant, however for some folk that remains open for debate.
The maven directory structure has been well thought out, I really like working on projects that use the maven directory structure, because they follow a convention that allows me to save a lot of time, by knowing from previous experience where to find the application components
java source
unit test source
resources etc.
Also by following the convention, the maven plugins work with less configuration required.
Another useful advantage that I get from working on maven based projects is good code metrics, to measure the health of the application. There are various report available as maven plugins, which will give you new insight into your codebase, including:
checkstyle
pmd
findbugs
and more.
Created a build directory where everything got copied before build
Added some flags to not copy over things that rarely change, like images (also to not remove them on clean)
Started using ant-reload task after deploying code
Now i don't need to restart tomcat on every build, and build takes much less time.